Layer-2 connectivity from switch to access node/gateway

ABSTRACT

Methods, systems, and apparatuses for providing layer-2 connectivity through a non-routed ground segment network, are described. A system includes a non-autonomous gateway in communication with a satellite configured to relay data packets. The non-autonomous gateway is configured to receive the data packets from the satellite at layer-1 (L1) of the OSI-model, generate a plurality of virtual tagging tuples within the layer-2 packet headers of the plurality of data packets. The non-autonomous gateway is further configured to transmit, at layer-2 (L2) of the OSI-model, the virtually tagged data packets. Each of the packets may include a virtual tagging tuple and an entity destination. The system further includes a L2 switch in communication with the non-autonomous gateway. The L2 switch may be configured to receive the data packets and transmit the data packets to the entity based on the virtual tuples associated with each of the data packets.

CROSS REFERENCES

This application is a Continuation of U.S. patent application Ser. No.15/931,250 entitled, “Layer-2 Connectivity From Switch To AccessNode/Gateway” filed May 13, 2020, which is a Continuation of U.S. patentapplication Ser. No. 16/251,360, entitled, “Layer-2 Connectivity FromSwitch To Access Node/Gateway” filed Jan. 18, 2019, which is acontinuation of U.S. patent application Ser. No. 15/715,004 entitled,“Layer-2 Connectivity From Switch To Access Node/Gateway” filed Sep. 25,2017, which is a continuation of U.S. patent application Ser. No.14/990,702 entitled, “Layer-2 Connectivity From Switch To AccessNode/Gateway”, filed Jan. 7, 2016, which is a continuation of U.S.patent application Ser. No. 13/739,173, entitled, “Layer-2 ConnectivityFrom Switch To Access Node/Gateway,” filed Jan. 11, 2013, which is acontinuation-in-part of U.S. patent application Ser. No. 12/761,834,entitled “Layer-2 Connectivity from Switch to Access Node/Gateway,”filed Apr. 16, 2010, which claims priority to U.S. ProvisionalApplication No. 61/170,359, entitled “Distributed Base Station SatelliteTopology,” filed on Apr. 17, 2009, and also claims priority to U.S.Provisional Application No. 61/254,551, entitled “Layer-2 Connectivityfrom Switch to Access Node/Gateway,” filed on Oct. 23, 2009. U.S. patentapplication Ser. No. 13/739,173 is also a continuation-in-part of U.S.patent application Ser. No. 12/761,882, entitled “Layer-2 ExtensionServices,” filed on Apr. 16, 2010, which claims priority to U.S.Provisional Application No. 61/170,359, entitled “Distributed BaseStation Satellite Topology,” filed on Apr. 17, 2009, and also claimspriority to U.S. Provisional Application No. 61/254,554, entitled“Layer-2 Extension Services,” filed on Oct. 23, 2009. U.S. patentapplication Ser. No. 13/739,173 is also a continuation-in-part of U.S.patent application Ser. No. 12/761,904, entitled “Mobility AcrossSatellite Beams Using L2 Connectivity,” filed on Apr. 16, 2010, whichclaims priority to U.S. Provisional Application No. 61/170,359, entitled“Distributed Base Station Satellite Topology,” filed on Apr. 17, 2009,and also claims priority to U.S. Provisional Application No. 61/316,776,entitled “Mobility Across Satellite Beams Using L2 Connectivity,” filedon Mar. 23, 2010. U.S. patent application Ser. No. 13/739,173 is also acontinuation-in-part of U.S. patent application Ser. No. 12/761,941,entitled “Multi-Satellite Architecture,” filed on Apr. 16, 2010, whichclaims priority to U.S. Provisional Application No. 61/170,359, entitled“Distributed Base Station Satellite Topology,” filed on Apr. 17, 2009,and also claims priority to U.S. Provisional Application No. 61/316,782,entitled “Multi-Satellite Architecture,” filed on Mar. 23, 2010. Theentirety of each of the above-identified applications are expresslyincorporated by reference herein for any and all purposes.

BACKGROUND

Satellite communications systems are becoming ubiquitous forcommunicating large amounts of data over large geographic regions. Intypical satellite communications systems, end consumers interface withthe systems through user terminals. The user terminals communicate, viaone or more satellites, with one or more gateways. The gateways may thenprocess and route the data to and from one or more networks according tovarious network protocols and tags processed at the network layer andabove (e.g., layers 3 and above of the Open System InterconnectionReference Model (OSI) stack). While utilizing higher layers to routecommunications may provide certain features, such as enhancedinteroperability, it may also limit certain capabilities of the network.For example, routing limits the types of tags that can persist acrossmultiple sub-networks.

Presently, gateways in satellite networks are configured to support anumber of services and perform a variety of network functions. Forexample, gateways perform IP Routing protocols, Layer-3 redundancyschemes, acceleration, AAA/Radius services (i.e., terminal registrationon the network), DHCP/DNS, trivial file transfer protocol (TFTP),network time protocol (NTP), public key encryption (PKI), and the like.Such gateways are expensive to build and maintain. Furthermore, theservices and functionality offered by these gateways are isolated to thecustomers for which the gateway specifically service. Many gatewaysproviding the same or similar services and must be maintained inparallel in order to provide service to an entire customer base over alarge geographical area.

Further, current implementations of satellite networks fail to providethe services and functionality at layer-2 (i.e., layer-2 of theOSI-model stack) communicating from one point on the network to another.Additionally, current implementations of satellite networks only provideredundancy within the gateway. For example, current satellite networkimplementations may provide redundant access to a points on the network(i.e., multiple fiber lines to a gateway such that if one line iscompromised, service still continues over the second line); however, if,for example, the gateway itself is down (or a service of the gateway),there is currently no way for another gateway to continue to provide theservice (or services) of a failed gateway.

Current gateway implementations typically communicate over layer-3 or“layer-2.5” (i.e., multi-protocol label switching (MPLS)). As such,networks using only layer-3 or layer-2.5 are limited in the services andnetwork configurations that can be offered. For example, an MPLS networkmay be deployed using RFC-2547 which is MPLS that redistributes routesusing border gateway protocol (BGP). Accordingly, such a deploymentincludes a layer-3 network over an MPLS underlying network, so each corenode or gateway is routed (i.e., the MAC header of packets transmittedare altered), thus limiting the capabilities of the network.

Additionally, in current mobile IP implementations each mobile device isidentified by its home address (i.e., at the mobile device's home agent)regardless of the mobile's device's current location. While the mobiledevice is away from its home network, the mobile device is assigned acare-of address. The care-of address identifies the mobile device'scurrent location. The care-of address acts as a local endpoint of atunnel back to the mobile device's home agent, and the home address. Assuch, mobile IP specifies how the mobile device registers with its homeagent and how the home agent routes data to the mobile device throughthe tunnel (between the home argent and the care-of address).

Mobile IP has significant drawbacks. One drawback is that the when themobile device moves out of its home location, the mobile device'scare-of address is a virtual address. Hence, moving out of the homelocation requires a hand off, which changes the mobile device's IPaddress by adding a care-of-address. This is particularly problematic inIPv4 networks (e.g., connectivity is temporarily lost, browser sessionis lost, VPN session is lost, etc.). In many applications (e.g., VPN,VoIP), sudden changes in network connectivity and IP address causessignificant problems. For example, an SSL tunnel for on-line bankingwill terminate. Furthermore, the tunnel between the home address and thecare-of address is a layer-3 protocol, and as such, the as the mobiledevice moves out of its home location the mobile device is no longerconnected to the same network (i.e., LAN, subnet, etc.). Additionally,traffic must be routed through the home agent location. For example, ifthe mobile device and the data the mobile device is accessing are at thesame remote location, the data must travel all the way to the home agentlocation and then circle back to the remote location, thus greatlyincreasing latency. Accordingly, current mobile IP implementations failto provide a persistent IP address and persistent connectivity andefficient data transfer over a large geographical area. For these and/orother reasons, it may be desirable to provide ground-segment networkingwith enhanced functionality.

SUMMARY

In one embodiment, a system for providing layer-2 connectivity through anon-routed ground segment network, is described. A system includes asatellite configured to transmit data packets. The system furtherincludes a non-autonomous gateway in communication with the satellite.The non-autonomous gateway is configured to receive the data packetsfrom the satellite at layer-1 (L1) of the OSI-model, generate aplurality of virtual tagging tuples within the layer-2 packet headers ofthe plurality of data packets. The non-autonomous gateway is furtherconfigured to transmit, at layer-2 (L2) of the OSI-model, the virtuallytagged data packets. Each of the packets including a virtual taggingtuple and an entity destination. The system further includes a L2 switchin communication with the non-autonomous gateway. The L2 switch isconfigured to receive the data packets and transmit the data packets tothe entity based on the virtual tuples associated with each of the datapackets. Further, the system may include a second non-autonomous gatewayin communication with the L2 switch. The second non-autonomous gatewaymay be configured to receive the virtually tagged data packets andtransmit the virtually tagged data packets to an entity based on thevirtual tagging tuple associated with each of the virtually taggedpackets.

In a further embodiment, a method for providing layer-2 connectivitythrough a non-routed ground segment network, is described. The methodincludes transmitting, by one or more satellites, data packets,receiving, at a non-autonomous gateway, the data packets from the one ormore satellites at layer-1 of the OSI-model (L1), and generating, by thenon-autonomous gateway, a plurality of virtual tagging tuples withinlayer-2 of the OSI-model (L2) packet headers of the plurality of datapackets. Furthermore, the method includes transmitting, by thenon-autonomous gateway at L2, the virtually tagged data packets, whereineach includes a virtual tagging tuple and an entity destination,receiving, at an L2 switch, the data packets, and transmitting, by theL2 switch, the data packets to the entity based on each of the virtualtuples associated with each of the data packets.

In yet a further embodiment, a computer-readable medium for providinglayer-2 connectivity through a non-routed ground segment network, isdescribed. The machine-readable medium includes instructions fortransmitting data packets, receiving the data packets from the one ormore satellites at layer-1 of the OSI-model (L1), and generating aplurality of virtual tagging tuples within layer-2 of the OSI-model (L2)packet headers of the plurality of data packets. The machine-readablemedium further includes instructions for transmitting, at L2, thevirtually tagged data packets, wherein each includes a virtual taggingtuple and an entity destination, receiving, at an L2 switch, the datapackets, and transmitting, by the L2 switch, the data packets to theentity based on each of the virtual tuples associated with each of thedata packets.

In another embodiment, a method of providing end-to-end layer-2connectivity throughout a non-routed ground segment network connected toone or more satellites, is described. The method includes transmitting,by the one or more satellites, data packets, receiving, at a firstnon-autonomous gateway in communication with the one or more satellites.The data packets from the one or more satellites at layer-1 (L1) of theOSI-model. The method further includes generating, by the firstnon-autonomous gateway, a plurality of virtual tagging tuples within thelayer-2 (L2) packet headers of the data packets. The plurality of datapackets each include a virtual tagging tuple. The method furtherincludes receiving, at a L2 switch in communication with the firstnon-autonomous gateway, the plurality of virtually tagged data packets,transmitting, by the L2 switch, the plurality of virtually tagged datapackets, and receiving, by a second non-autonomous gateway incommunication with the L2 switch, the plurality of virtually tagged datapackets. Further, the method includes transmitting, by the secondnon-autonomous gateway, the plurality of virtually tagged data packetsto an entity based on the virtual tagging tuple associated with each ofthe plurality of virtually tagged packets.

In yet another embodiment, a machine-readable medium for providingend-to-end layer-2 connectivity throughout a non-routed ground segmentnetwork connected to one or more satellites, is described. Themachine-readable medium includes instructions for transmitting, by theone or more satellites, data packets, receiving, at a firstnon-autonomous gateway in communication with the one or more satellites.The data packets from the one or more satellites at layer-1 (L1) of theOSI-model. The machine-readable medium further includes instructions forgenerating, by the first non-autonomous gateway, a plurality of virtualtagging tuples within the layer-2 (L2) packet headers of the datapackets. The plurality of data packets each include a virtual taggingtuple. The machine-readable medium further includes instructions forreceiving, at a L2 switch in communication with the first non-autonomousgateway, the plurality of virtually tagged data packets, transmitting,by the L2 switch, the plurality of virtually tagged data packets, andreceiving, by a second non-autonomous gateway in communication with theL2 switch, the plurality of virtually tagged data packets. Further, themachine-readable medium includes instructions for transmitting, by thesecond non-autonomous gateway, the plurality of virtually tagged datapackets to an entity based on the virtual tagging tuple associated witheach of the plurality of virtually tagged packets.

In one embodiment, a method of providing layer-2 extension servicesthrough a non-routed ground segment network is described. The methodincludes providing a Layer-2 (L2) interface between a node of thenon-routed ground segment network and a service provider, assigning avirtual tagging tuple to the service provider and receiving serviceprovider traffic at a node of the non-routed ground segment network. Themethod further includes tagging the service provider traffic with thevirtual tagging tuple, and switching the tagged service provider trafficthrough the non-routed ground segment network according to the virtualtagging tuple.

In one embodiment, a system for providing layer-2 extension servicesthrough a non-routed ground segment network is described. The systemincludes a plurality of nodes of the non-routed ground segment network.The nodes are in communication with each other over a substantiallypersistent layer-2 connection. The system further includes a first nodeis locally coupled with a layer-2 network associated with a serviceprovider. The service provider being associated with a virtual taggingtuple. The system also includes a second node is in operativecommunication with a plurality of customers. The second node beinggeographically remote from the first node. At least a portion of trafficcommunicated with the plurality of customers and associated with theservice provider is tagged with the virtual tagging tuple, and each ofthe plurality of nodes is configured to switch the portion of thetraffic at L2 according to the virtual tagging tuple.

In one embodiment, a machine-readable medium for providing layer-2extension services through a non-routed ground segment network isdescribed. The machine-readable medium includes instructions forproviding a Layer-2 (L2) interface between a node of the non-routedground segment network and a service provider, assigning a virtualtagging tuple to the service provider and receiving service providertraffic at a node of the non-routed ground segment network. Themachine-readable medium further includes instructions for tagging theservice provider traffic with the virtual tagging tuple, and switchingthe tagged service provider traffic through the non-routed groundsegment network according to the virtual tagging tuple.

In one embodiment, a system for providing mobility across satellitebeams is described. The system includes a first core node, a second corenode in communication with the first core node at layer-2 of the OSImodel (L2), and a first gateway in communication, at L2, with the firstcore, the first gateway configured to provide access to a first spotbeam at a first location. The system further includes a second gatewayin communication, at L2, with the second core node, the second gatewayconfigure to provide access to a second spot beam at a second location,and a mobile device, at the first location, in communication with thefirst gateway via the first spot beam, wherein the mobile device isassigned an IP address by the first core node. The mobile device movesfrom the first location to the second location. Further, the firstgateway, in response to the mobile device moving from the first locationto the second location, notifies the second gateway, through the firstcore node and the second core node, that the mobile device is moving tothe second location, and transmits the session information to the secondgateway, and the second gateway, in response to the notification,maintains connectivity with the mobile device using the IP address.

In one embodiment, a method of providing mobility across satellite beamsis described. The method includes providing access to a first spot beamat a first location serviced by a first gateway, providing access to asecond spot beam at a second location serviced by a second gateway, andassigning a mobile device, at the first location, an IP address by thefirst gateway. The mobile device moves from the first location to thesecond location. The method further includes in response to the mobiledevice moving from the first location to the second location, notifyingthe second gateway, through a first core node and a second core node,that the mobile device is moving to the second location, transmittingthe session information to the second gateway and in response to thenotification, maintaining connectivity with the mobile device using theIP address.

In one embodiment, a computer-readable medium for providing mobilityacross satellite beams is described. The computer-readable mediumincludes instructions for providing access to a first spot beam at afirst location serviced by a first gateway, providing access to a secondspot beam at a second location serviced by a second gateway, andassigning a mobile device, at the first location, an IP address by thefirst gateway. The mobile device moves from the first location to thesecond location. The computer-readable medium further includesinstructions for in response to the mobile device moving from the firstlocation to the second location, notifying the second gateway, through afirst core node and a second core node, that the mobile device is movingto the second location, transmitting the session information to thesecond gateway and in response to the notification, maintainingconnectivity with the mobile device using the IP address.

In one embodiment, a satellite networking system is described. Thesystem includes a first satellite, a second satellite, and a corenetwork. The core node is configured to provide a plurality of services.The system further includes a first gateway in communication with thefirst satellite and the core network, and a second gateway incommunication with the second satellite and the core network. The firstsatellite is configured to share the plurality of services with thesecond satellite through the first and second gateways.

In one embodiment, a satellite networking system is described. Thesystem includes a first satellite which is of a first satellite type.The system further includes a second satellite which is of a secondsatellite type. The system includes a gateway in communication with thefirst and second satellite. The first satellite is configured to share aplurality of services with the second satellite through the gateway.

In one embodiment, another satellite networking system is described. Thesystem includes a first satellite, a second satellite, a first gatewayin communication with the first satellite, and a second gateway incommunication with the second satellite. The system further includes afirst core in communication with the first gateway, and a second core incommunication with the first core and the second gateway. The first andsecond cores are in communication over a virtual private network (VPN).The first satellite is configured to share a plurality of services withthe second satellite through the first and second gateways and the firstand second cores.

In one embodiment, a method of implementing a multi-satellite network isdescribed. The method includes providing a first satellite, providing asecond satellite, and providing a core network configured to provide aplurality of services. The method further includes providing a firstgateway in communication with the first satellite and the core network,and providing a second gateway in communication with the secondsatellite and the core network. The first satellite is configured toshare the plurality of services with the second satellite through thefirst and second gateways.

In one embodiment, a system for implementing a satellite network isdescribed. The system includes satellite gateways in communication withsubscribers over a satellite communication network. The satellitegateways send network communications to the subscribers and receivenetwork communications from the subscribers. The system further includesa first core node in communication with at least one of the satellitegateways. The first core node provides networking services, at L2, to afirst subset of subscribers. The system further includes a second corenode in communication, at L2, with one of the satellite gateways and thefirst core node. The second core node provides the networking services,at layer-2 of the OSI model, to a second subset of the subscribers. Inresponse to failure of at least one of the networking services in thefirst core node, the second core node providing the at least one of theservices to the first subset of the subscribers.

In one embodiment, a satellite networking system is described. Thesystem includes a first core node in communication, at layer-2 of theOSI model (L2), with a first satellite gateway. The system furtherincludes a second core node in communication, at L2, with a secondsatellite gateway and the first core node. Further, the system includesa peering node in communication, at L2, with the first satellitegateway. The peering node is configured to provide content or servicesat the first satellite gateway. Further, the peering node is configuredto provide content or services at anyone of the first code node, thesecond core node, and the second satellite gateway.

In one embodiment, a method of implementing a redundant core nodearchitecture in a satellite communication network is described. Themethod includes providing, at a first core node, a plurality ofservices, at layer-2 of the OSI model (L2), to a first plurality ofsubscribers through a first satellite gateway. The method furtherincludes providing, at a second core node, the services, at L2, to asecond plurality of subscribers through a second satellite gateway andthe first core node. receiving, at the second core node, a failurenotification of at least one of the plurality of services provided bythe first core node, and in response to the failure notification,providing, by the second core node, the at least one of the plurality ofservices to the first plurality of subscribers.

In one embodiment, a computer-readable medium for implementing aredundant core node architecture in a satellite communication network isdescribed. The computer-readable medium includes instructions forproviding, at a first core node, a plurality of services, at layer-2 ofthe OSI model (L2), to a first plurality of subscribers through a firstsatellite gateway. The computer-readable medium further includesinstructions for providing, at a second core node, the services, at L2,to a second plurality of subscribers through a second satellite gatewayand the first core node, receiving, at the second core node, a failurenotification of at least one of the plurality of services provided bythe first core node, and in response to the failure notification,providing, by the second core node, the at least one of the plurality ofservices to the first plurality of subscribers.

In one embodiment, a method of implementing acceleration through apacket encapsulation protocol tunnel is described. The method includesestablishing a packet encapsulation protocol tunnel between a firstnetwork endpoint and a second network endpoint, sending packets with apacket encapsulation protocol tunnel header from the first networkendpoint to the second network endpoint, and removing the packetencapsulation protocol tunnel headers from the packets. The methodfurther includes storing the packet encapsulation protocol tunnelheaders in a storage memory, performing acceleration on the packets, andretrieving the packet encapsulation protocol tunnel headers from thestorage memory. Further, the method includes replacing the packetencapsulation protocol tunnel headers on the packets, and sending thepackets with the packet encapsulation protocol tunnel headers throughthe packet encapsulation protocol tunnel to the second endpoint.

In one embodiment, a system for implementing acceleration through apacket encapsulation protocol tunnel is described. The system includes acustomer premises device (CPE) configured to transmit a packet with anetwork request. The packet includes a header and a destination. Thesystem further includes a user terminal (UT) in communication with theCPE configured to receive the packet. Further, the system includes asatellite in communication with the UT configured to transmit thepacket. The system also includes a satellite modem termination system(SMTS) in communication with the satellite. The SMTS is configured toreceive the packet, establish a packet encapsulation protocol tunnelbetween the SMTS and a gateway module, and place a packet encapsulationprotocol tunnel header within the packet header. Then, a core node is incommunication with the SMTS, and includes acceleration modules, thegateway module, and a storage memory. The acceleration module isconfigured to receive the packets, remove the packet encapsulationprotocol tunnel header, store the packet encapsulation protocol tunnelheader in the storage memory, and perform acceleration on the packet.The gateway module is further configured to receive the packet afteracceleration, retrieve the packet encapsulation protocol tunnel headerfrom the storage memory, replace the packet encapsulation protocoltunnel header on header of the packet, and transmit the packet to thedestination.

In one embodiment, a computer-readable medium for implementingacceleration through a packet encapsulation protocol tunnel isdescribed. The computer-readable medium includes instructions forestablishing a packet encapsulation protocol tunnel between a firstnetwork endpoint and a second network endpoint, sending packets with apacket encapsulation protocol tunnel header from the first networkendpoint to the second network endpoint, and removing the packetencapsulation protocol tunnel headers from the packets. Thecomputer-readable medium further includes instructions for storing thepacket encapsulation protocol tunnel headers in a storage memory,performing acceleration on the packets, and retrieving the packetencapsulation protocol tunnel headers from the storage memory. Further,the computer-readable medium includes instructions for replacing thepacket encapsulation protocol tunnel headers on the packets, and sendingthe packets with the packet encapsulation protocol tunnel headersthrough the packet encapsulation protocol tunnel to the second endpoint.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of the presentinvention may be realized by reference to the following drawings. In theappended figures, similar components or features may have the samereference label. Further, various components of the same type may bedistinguished by following the reference label by a dash and a secondlabel that distinguishes among the similar components. If only the firstreference label is used in the specification, the description isapplicable to any one of the similar components having the same firstreference label irrespective of the second reference label.

FIG. 1 illustrates a typical satellite communications system inaccordance with various embodiments.

FIG. 2 shows an embodiment of a satellite communications system having anumber of user terminals in communication with a non-autonomous gatewayvia a satellite, according to various embodiments

FIG. 3 shows an embodiment of a satellite communications system having anon-autonomous gateway in communication with nodes of a non-routedground segment network, according to various embodiments.

FIG. 4A shows an embodiment of a satellite communications system usedfor communication between two clients over a non-routed ground segmentnetwork, according to various embodiments.

FIG. 4B shows an illustrative communication link for an enterprisecustomer in a system in communication with an enterprise network,according to various embodiments.

FIG. 4C shows an illustrative data flow through the link in FIG. 4B,according to various embodiments.

FIG. 5 illustrates a non-autonomous gateway shown as part of a portionof a non-routed ground segment network, according to variousembodiments.

FIG. 6A shows an embodiment of a communications system having multiplenon-autonomous gateways in communication with a more detailedillustrative embodiment of a core node, according to variousembodiments.

FIG. 6B shows embodiments of various modules in communication with oneor more multilayer switches, according to various embodiments

FIG. 7A illustrates an alternative architecture of a core node,according to various embodiments.

FIG. 7B illustrates traffic shaper module operating separately fromgateway module, according to various embodiments.

FIG. 7C illustrates one embodiment of a core-based network architectureimplementing a non-routed ground segment network, according to variousembodiments.

FIG. 8 shows an embodiment of an autonomous gateway, according tovarious embodiments.

FIG. 9 shows an embodiment of a satellite communications system thatdistributes autonomous gateways and non-autonomous gateways across anumber of geographically dispersed regions, according to variousembodiments.

FIG. 10 shows an embodiment of a portion of a communications systemconfigured to facilitate layer-2 extension services, according tovarious embodiments.

FIG. 11 shows an illustrative flow diagram of a method of implementinglayer-2 connectivity within a satellite ground segment backhaul network,according to various embodiments.

FIG. 12 shows an illustrative flow diagram of a method for implementingaccess node/gateway to access node/gateway layer-2 connectivity within abackhaul ground segment network connected to one or more satellites,according to various embodiments.

FIG. 13 shows a flow diagram of a method for providing layer-2 extensionservices across a non-routed ground segment network, according tovarious embodiments.

FIG. 14 shows a block diagram of a system for implementing mobilityacross satellite spot beams, according to various embodiments.

FIG. 15 illustrates a system for providing mobility access acrosssatellite spot beams, according to various embodiments.

FIG. 16 illustrates a method of providing mobility access acrosssatellite spot beams, according to various embodiments.

FIG. 17 illustrates a network for implementing layer-2 connectivity formultiple satellites with a single gateway, according to variousembodiments.

FIG. 18 illustrates a network for implementing layer-2 connectivity formultiple satellites with multiple gateways, according to variousembodiments.

FIG. 19 illustrates a network for implementing layer-2 connectivity formultiple satellites with multiple gateways and multiple cores, accordingto various embodiments.

FIG. 20 illustrates a flow diagram describing a method of implementingredundancy among core nodes, according to various embodiments.

FIG. 21 shows a block diagram of a network for implementing accelerationthrough a tunnel, according to various embodiments.

FIG. 22, the diagram illustrates the forward link portion of the networkof FIG. 21, according to various embodiments.

FIG. 23A shows a block diagram of a network flow for implementingacceleration through a network tunnel, according to various embodiments.

FIG. 23B shows a block diagram of a network flow for implementingacceleration through a network tunnel, according to various embodiments.

FIG. 24 shows a flow diagram of a method for implementing accelerationthrough a network tunnel, according to various embodiments.

FIG. 25 is a simplified block diagram illustrating the physicalcomponents of a computer system that may be used in accordance withvarious embodiments.

DETAILED DESCRIPTION OF THE INVENTION

The ensuing description provides exemplary embodiment(s) only, and isnot intended to limit the scope, applicability or configuration of thedisclosure. Rather, the ensuing description of the exemplaryembodiment(s) will provide those skilled in the art with an enablingdescription for implementing an exemplary embodiment, it beingunderstood that various changes may be made in the function andarrangement of elements without departing from the spirit and scope asset forth in the appended claims. Some of the various exemplaryembodiments may be summarized as follows.

In many typical satellite communications systems, end consumersinterface with the systems through user terminals. The user terminalscommunicate, via one or more satellites, with one or more gateways. Thegateways may then process and route the data to and from one or morenetworks according to various network protocols and tags processed atthe network layer and above (e.g., layers 3 and above of the Open SystemInterconnection Reference Model (OSI) stack).

For example, FIG. 1 illustrates a typical satellite communicationssystem 100. The satellite communications system 100 includes a number ofuser terminals 130 in communication with a gateway 115 via a satellite105. For example, a subscriber of satellite communications servicesdesires to access a web page using a browser. The subscriber's client160 (e.g., a client application running on customer premises equipment(CPE) controlled by the subscriber) may communicate an HTML requestthrough a respective one of the user terminals 130. A user antenna 135in communication with the respective user terminal 130 communicates therequest to the satellite 105, which, in turn, sends the request to thegateway 115 through a provider antenna 125.

The gateway 115 receives the request at a base station 145 configured toservice that user terminal 130 and included within a satellite modemtermination system (SMTS) 140. The SMTS 140 sends the request data to arouting module 150, in communication with a gateway module 155. Therouting module 150 and gateway module 155 work together to determine andgenerate routing data for communicating the request data through arouted ground segment network 120. Typically, the gateway module 155 maybe a control plane application which sets up connectivity to the router.Even where actual routing is not done by the gateway module 155,components of the gateway 115 may implement routing functions.

As used herein, a “routed network” refers to a network having a numberof routers, configured to use protocols at layer-3 and above of the OSIstack (e.g., or substantially equivalent types of protocols) to routedata through the network. The “routing module,” as used herein, isintended to broadly include any type of network device configured toroute at layers 3 and above of the OSI stack (e.g., or providesubstantially similar network layer functionality). Particularly,routing is intended to be distinguished from switching (e.g., at layer 2of the OSI stack (e.g., or substantially similar functionality), as willbecome more clear from the description below.

While utilizing higher layers to route communications may providecertain features, such as enhanced interoperability, it may also limitcertain capabilities of the network. As one exemplary limitation, ateach node where a layer-3 routing decision is made, determining theappropriate routing may involve parsing packet headers, evaluatingparsed header information against routing tables and port designations,etc. These steps may limit the amount and type of traffic that can besent over the network, as well as the protocols available for transporton the network.

In another exemplary limitation, at each router, layer-2 headers aretypically stripped off and replaced with other tags to identify at leastthe next routing of the data through the network. As such, it isimpossible to maintain a single network between routed terminals. Inother words, a packet which is generated at one LAN, passes through oneor more routers (i.e., at layer-3 or above) and is received at anotherLAN, will always be considered to be received from a different network.Accordingly, virtual networking protocols such as, VPN, MPLS, etc. mustbe used for sending traffic between one gateway 115 and another gateway115. Furthermore, depending on the type of service, if the service orservices fail on one gateway 115, then other gateways 115 may be unableto provide the failed service or services to subscribers connected tothe failed gateway 115 (the two gateways are, from a networkingprospective, isolated). However, if the traffic between each gateway 115was switched at layer-2, then other gateways 115 would be able toprovide the failed service or services to the subscribers connected tothe failed gateway 115. It can be appreciated that some benefits of asingle network configuration are unattainable in a layer-3 routednetwork. For example, tags for supporting proprietary service providernetworks, Multiprotocol Label Switching (MPLS), and/or other types ofnetworks are impossible to maintain across large geographic regions(e.g., multiple LANs, WANs, subnets, etc.) of a routed ground segmentnetwork 120.

In the illustrative example, internet protocol (IP) and/or other tagsare used to route the request data to an appropriate IP address for usein satisfying the subscriber's request. When a response to the requestis received by the routed ground segment network 120, layer-3 and/orhigher-layer tags are again used to route the response data through thenetwork to the appropriate base station 145 in the appropriate gateway115. The base station 145 then communicates the response data to theclient 160 via the provider antenna 125, the satellite 105, thesubscriber antenna 135, and the user terminal 130.

Embodiments address these limitations of the routed ground segmentnetwork 120 in various ways, for example, through the use of core nodes.FIG. 2 shows an embodiment of a satellite communications system 200having a number of user terminals 130 in communication with anon-autonomous gateway 215 via a satellite 105, according to variousembodiments. The non-autonomous gateway 215 is in communication withother nodes of a non-routed ground segment network 220 (e.g., othernon-autonomous gateways 215) via one or more core nodes 265. Embodimentsof the satellite communications system 200 effectively provide mesh-likelayer-2 connectivity between substantially all the nodes of thenon-routed ground segment network 220.

In various embodiments, components of the non-routed ground segmentnetwork 220 (e.g., components of the gateways 215, core nodes 265, etc.)are implemented, in whole or in part, in hardware. They may include oneor more Application Specific Integrated Circuits (ASICs) adapted toperform a subset of the applicable functions in hardware. Alternatively,the functions may be performed by one or more other processing units, onone or more integrated circuits. In other embodiments, other types ofintegrated circuits may be used (e.g., Structured/Platform ASICs, FieldProgrammable Gate Arrays and other Semi-Custom ICs), which may beprogrammed. Each may also be implemented, in whole or in part, withinstructions embodied in a computer-readable medium, formatted to beexecuted by one or more general or application specific controllers.

In various embodiments, the satellite 105 is a geostationary satellite,configured to communicate with the user terminals 130 and gateways 215using reflector antennae, lens antennae, array antennae, phased arrayantennae, active antennae, or any other mechanism for reception of suchsignals. In some embodiments, the satellite 105 operates in a multi-beammode, transmitting a number of narrow beams, each directed at adifferent region of the earth. With such a multibeam satellite 105,there may be any number of different signal switching configurations onthe satellite 105, allowing signals from a single gateway 215 to beswitched between different spot beams. In one embodiment, the satellite105 is configured as a “bent pipe” satellite, wherein the satellite 105may frequency convert the received carrier signals before retransmittingthese signals to their destination, but otherwise perform little or noother processing on the contents of the signals. In various embodiments,there could be a single carrier signal or multiple carrier signals foreach service or feeder spot beam. In some embodiments, the subscriberantenna 135 and user terminal 130 together comprise a very smallaperture terminal (VSAT), with the subscriber antenna 135 measuring lessthan one meter in diameter and having approximately 2 watts of power. Inother embodiments, a variety of other types of subscriber antennae 135may be used at the user terminal 130 to receive the signal from thesatellite 105.

In certain embodiments, the satellite communications system 200 has itsnodes (e.g., non-autonomous gateways 215, core nodes 265, etc.)distributed over a large geographic region (e.g., across the UnitedStates of America). Each core node 265 may be configured to support upto twenty non-autonomous gateways 215, each non-autonomous gateway 215may be configured to support up to four user links, and each user linkmay support thousands of clients 160. For example, the satellite 105 mayoperate in a multi-beam mode, transmitting a number of spot beams, eachdirected at a different region of the earth. Each spot beam may beassociated with one of the user links, and used to communicate betweenthe satellite 105 and thousands of user terminals 130. With such amulti-beam satellite 105, there may be any number of different signalswitching configurations on the satellite 105, allowing signals from asingle gateway 215 to be switched between different spot beams.

In one illustrative case, a subscriber of satellite communicationsservices desires to access a web page using a browser. The subscriber'sclient 160 (e.g., a client application running on customer premisesequipment controlled by the subscriber) may communicate an HTML requestthrough a respective one of the user terminals 130. A user antenna 135in communication with the respective user terminal 130 communicates therequest to the satellite 105, which, in turn, sends the request to thenon-autonomous gateway 215 through a provider antenna 125.

The non-autonomous gateway 215 receives the request at a base station245 configured to service that user terminal 130 and included within asatellite modem termination system (SMTS) 240. Unlike in FIG. 1, wherethe SMTS 140 sends the request data to a routing module 150, the SMTS240 of FIG. 2 sends the request data to one or more layer-2 (L2)switches 247. The L2 switches 247 forward the data to a core node 265 orother node of the non-routed ground segment network 220 according tolayer-2 (e.g., or substantially equivalent) information. For example,unlike the router module 150 of FIG. 1, the L2 switches 247 may notexpend substantial resources analyzing higher layer tags (e.g., parsing1P headers) and may not strip off tags for the sake of packet routing.Furthermore, all terminals, code nodes, non-autonomous gateways,autonomous gateways, etc. are all able to be on a single contiguousnetwork.

In some embodiments, all data in the non-routed ground segment network220 being communicated between two non-autonomous gateways 215 passesthrough at least one core node 265. The core node 265 may include one ormore multilayer switches 250 and a gateway module 255. It is worthnoting that, while embodiments of the typical gateway 115 of FIG. 1 areshown to include gateway modules 155, embodiments of the non-autonomousgateways 215 do not include gateway modules 255. In some embodiments,the gateway module 255 of the core node 265 is substantially the same asthe gateway module 155 of FIG. 1.

When data is received at the core node 265 it may be processed in anumber of different ways by the one or more multilayer switches 250. Insome embodiments, the multilayer switches 250 process higher-layerinformation to provide certain types of functionality. For example, itmay be desirable to handle packets in certain ways according to virtualprivate networking (VPN) tags, voice-over-IP (VoIP) designations, and/orother types of higher-layer information.

It is worth noting that embodiments of the multilayer switches 250 areconfigured to process routing-types of information without strippingdata from the packets. In this way, embodiments of the satellitecommunications system 200 effectively provide mesh-like layer-2connectivity between substantially all the nodes of the non-routedground segment network 220. One feature of this type of layer-2connectivity is that embodiments may perform higher layer processingonly (e.g., or primarily) at the core nodes 265, which may substantiallyspeed up communications through the non-routed ground segment network220. Another feature is that embodiments of the non-routed groundsegment network 220 may allow certain types of information (e.g., VPLStags, proprietary network services tags, etc.) to persist acrossmultiple sub-networks. These and other features will be furtherappreciated from the description below.

In some embodiments, the layer-2 connectivity across the non-routedground segment network 220 is further enabled through the use of virtualtagging tuples. FIG. 3 shows an embodiment of a satellite communicationssystem 300 having a user terminal 130 in communication with anon-autonomous gateway 215 via a satellite 105, where the non-autonomousgateway 215 is further in communication with nodes of a non-routedground segment network 220 using virtual tagging tuples 375, accordingto various embodiments. As illustrated, the non-autonomous gateway 215is in communication with other nodes of the non-routed ground segmentnetwork 220 via a tuple-enabled communication link 370.

Embodiments of the tuple-enabled communication link 370 are configuredto carry traffic according to a virtual tagging tuple 375. The virtualtagging tuple 375 may be configured to have one or more elements thatvirtually define information about data relevant to communicating thedata through the non-routed ground segment network 220. In oneembodiment, the tuple-enabled communication link 370 is implemented as a10-Gigabit LAN PHY cable (an Ethernet cable configured according tocertain local area network (LAN) physical layer (PHY) standards).

Each virtual tagging tuple 375 may “reserve” or “carve out” a certainportion of the tuple-enabled communication link 370 (e.g., the fibertrunk) Each portion may be associated with (e.g., purchased by) anentity. For example, the tuple-enabled communication link 370 may bevirtually shared among a number of entities via the virtual taggingtuples 375, and the allotment for each entity may be based on the amountcarved out for the entity. For example, if the tuple-enabledcommunication link 370 represents ten Gigabits per second to “sell,”virtual tagging tuples 375 may be purchased in fractions of that linkcapacity (e.g., one-Gigabit increments). Each entity may then beserviced according to a quality of service structure or other servicelevel agreement, according to the capacity purchased. Further, eachentity may be provided with certain types of functionality associatedwith one or more of its virtual tagging tuples 375.

In one embodiment, the tuple-enabled communication link 370 is afiber-optic trunk configured according to IEEE Standard 802.1Q-2005.Each virtual tagging tuple 375 may be implemented as a “VLAN tag”according to the 802.1Q standard. For example, where the tuple has twoelements, “double tagging,” or “Q-in-Q” tagging may be used according tothe 802.1Q standard.

For example, a request for content (e.g., an HTML, page, a documentfile, a video file, an image file, etc.) is sent from a client 160client to a user terminal 130. The request is transmitted up to thesatellite 105 and back down to the non-autonomous gateway 215 via thesubscriber antenna 135 and the provider antenna 125. Components of thenon-autonomous gateway 215 (e.g., one or more L2 switches 247) areconfigured to add virtual tagging tuples 375 to the data packets.

The virtual tagging tuples 375 added to the data packets may include anentity designation and a location of the entity, implemented as anordered pair. For example, the entity may be “XYZ Corp,” with an entitydesignation of “205” (or some other numeric, alpha, or alphanumericdesignation). Furthermore, “XYZ Corp.” may be associated with any numberof locations. For example, “XYZ Corp.” may have locations in Denver,Colo., San Francisco, Calif., and Rapid City, S. Dak., and each of theselocations may be assigned a location identifier. For example, Denver,Colo. may be assigned “001,” San Francisco, Calif. may be assigned“360,” and Rapid City, S. Dak. may be assigned “101,” as their locationidentifiers. Accordingly, virtual tagging tuple 375 “(205, 001)” mayindicate traffic associated with “XYZ Corp.” and destined for Denver,Colo., while virtual tagging tuple 375 “(205, 101)” would indicatetraffic associated with “XYZ Corp.” and destined for Rapid City, S. Dak.

Additional entity designations may be generated. For example, “Co. A”may have a “D24” designation, while “Co. C” may have a “450”designation. Furthermore, location identifiers may be used by multipleentities. For example, virtual tagging tuple 375 “(D24, 360)” mayindicate traffic assigned to “Co. A” destined for San Francisco, Calif.,while virtual tagging tuple 375 “(205, 360)” indicates traffic assignedto “XYZ Corp.” also destined for San Francisco. Alternatively, eachentity my have its own customized location identifier(s).

In various embodiments of the non-routed ground segment network 220, thevirtual tagging tuples 375 are used to communicate the packetsthroughout the network without using port-based routing, destinationaddresses, header parsing, etc. The packets may effectively becommunicated among nodes of the non-routed ground segment network 220 asif the nodes are part of a single subnet. Even geographically remotenon-autonomous gateways 215 may communicate as if part of a local areanetwork (LAN). For example, as described above, based on virtual taggingtuple 375 entity and location designations, packets may be forwarded todesignated locations anywhere in the non-routed ground segment network220. The virtual tagging tuples 375 may be used by gateway modules,switches, cross-connects, core nodes, peering routers, and/or any othernode of the non-routed ground segment network 220.

In various embodiments, clients 160 may use the satellite communicationssystem 300 to communicate, via the non-routed ground segment network220, to any addressable location in communication with the non-routedground segment network 220. For example, clients 160 may communicatewith service providers, the Internet, content delivery networks (CDNs),other clients 160, etc. FIG. 4A shows an embodiment of a satellitecommunications system 400 used for communication between two clients 160over a non-routed ground segment network, according to variousembodiments. In some embodiments, the satellite communications system400 is substantially equivalent (e.g., an extended illustration of) thesatellite communications system 200 of FIG. 2.

A first client 160 a is in communication with a first non-autonomousgateway 215 a via a respective subscriber antenna 135 a and providerantenna 125, and the satellite 105. The first non-autonomous gateway 215a is in communication with one or more core nodes 265 (illustrated as afirst core node 265 a and an nth core node 265 n). For example, data iscommunicated from the first client 160 a, destined for a second client160 b. The data is received by a first base station 245 a in a firstSMTS 240 in the first non-autonomous gateway 215 a. The data is thenswitched by one or more first L2 switches 247 a and sent over a firstLAN PHY cable 370 a to one or more first multilayer switches 250 a inthe first core node 265 a. In the first core node 265 a, the data fromthe first client 160 a may be processed (e.g., interpreted, parsed,switched, etc.) at one or more layers by the first multilayer switches250 a and/or a first gateway module 255 a.

The first core node 265 a is in communication with at least a secondcore node 265 b. The first core node 265 a may determine, for example asa function of an associated virtual tagging tuple 375 or a higher-layertag, that the data from the first client 160 a should be passed to thesecond core node 265 b. The second core node 265 b may further processthe communications at one or more layers by second multilayer switches250 b and/or a second gateway module 255 b.

The second core node 265 b may pass the data to an appropriate secondnon-autonomous gateway 215 b, for example, over a second LAN PHY cable370 b. The second non-autonomous gateway 215 b may then switch the dataat layer 2 and pass the data to an appropriate second base station 245 bin a second SMTS 240 b in the second non-autonomous gateway 215 b. Forexample, the second base station 245 b is configured to support (e.g.,or is currently switched or tuned to support) a spot beam being used toservice the second client 160 b. The second base station 245 b maycommunicate the data from the second non-autonomous gateway 215 b to thesecond client 160 b via a respective provider antenna 125 b andsubscriber antenna 135 b, and the satellite 105.

It is worth noting that, while the first core node 265 a and/or thesecond core node 265 b may process the data at multiple layers,embodiments of the core nodes 265 are configured to maintain layer-2connectivity across the communication. In fact, the non-autonomousgateways 215, core nodes 265, and other nodes may all be part of anon-routed ground segment network (e.g., like the non-routed groundsegment network 220 of FIG. 2), and embodiments of the non-routed groundsegment network may effectuate layer-2 connectivity between any two ofits nodes. For example, the first non-autonomous gateway 215 a and thesecond non-autonomous gateway 215 b act as if they are on a singlesubnet (e.g., LAN), regardless of the number of nodes through which thedata passes, the distance over which it is communicated, the number ofsub-networks employed, etc.

It will be appreciated that a large non-routed ground segment networkmay include a number of different types of nodes, for example, toaccount for various client densities and locations, topologies (e.g.,mountain ranges, lakes, etc.), etc. Furthermore, satellitecommunications network 400 enables, for example, client 1 160 a andclient 2 160 b to function on the same network. As such, both clientsare able to have an IP address on the same sub-net (e.g., 192.168.1.*),receive the same services, receive a multicast or a broadcast message,etc. In other words, client 1 and client 2 are able to be connected inthe same manner similar to if were located in the same room connected tothe same switch.

Of course many of these features further involve use of one or moretypes of data stack throughout a communication link. For example, FIG.4B shows an illustrative communication link for an enterprise customerin a system in communication with an enterprise network 405, like theone shown in FIG. 4A, and FIG. 4C shows an illustrative data flowthrough the link in FIG. 4B. As illustrated, the communication link 450of FIG. 4B provides connectivity between a client (e.g., enterprisecustomer premises equipment (CPE)) 160 and an enterprise head-end 405.Communications on the communication link 450 may pass from theenterprise remote site to a gateway 215 (e.g., from the CPE 160 to thegateway via a user terminal and a satellite link 105), from the gateway215 to a core node 265 (e.g., from an L2 backhaul switch in the gatewayto an gateway and L2/L3 switch in the core), and from the core to theenterprise head-end 405 (e.g., from the L2/L3 switch in the core to apeer router in the head-end via a leased line). The data flow 460 inFIG. 4C shows illustrative data stacks at various locations (410, 415,420, and 425) in the communication link 450 of FIG. 4B. It is worthnoting, for example, that the bottom four layers of the illustrativedata stack remains intact throughout the communication link 450.

As discussed above, the non-routed ground segment network (e.g., likethe network 400 of FIG. 4A) may include a number of different types ofnodes in various types of configurations. Some of these different typesof nodes and node configurations are described with reference to FIGS.5-9. Turning first to FIG. 5, an embodiment of a non-autonomous gateway215 is shown as part of a portion of a non-routed ground segment network220.

The non-autonomous gateway 215 includes a number of SMTSs 240.Embodiments of each SMTS 240 include multiple base stations. Forexample, each base station may be implemented on a circuit card or othertype of component integrates into the SMTS 240. The illustratednon-autonomous gateway 215 includes four SMTSs 240, each incommunication with two L2 switches 247. For example, each SMTS 240 iscoupled with both L2 switches 247 to provide redundancy and/or otherfunctionality. Each L2 switch 247 may then be in communication (e.g.,directly or via other nodes of the non-routed ground segment network 220that are not shown) with one or more core nodes 265. For example, eachL2 switch 247 may be in communication with a single core node 265, sothat the non-autonomous gateway 215 is effectively in substantiallyredundant communication with two core nodes 265.

Embodiments of the non-autonomous gateway 215 are configured to supportother types of communication, for example, with other networks. In oneembodiment, one or more service providers are in communication with thenon-routed ground segment network 220 via one or both of the L2 switches247 or one or more of the core nodes 265. In one embodiment, thenon-autonomous gateway 215 includes an access router 560. The accessrouter 560 may be configured to interface with (e.g., provideconnectivity with) one or more out-of-band networks 570.

As described above, the L2 switches 247 in the non-autonomous gateway215 are in communication with one or more core nodes 265 so as tofacilitate persistent layer-2 connectivity. FIG. 6A shows an embodimentof a communications system 600 having multiple non-autonomous gateways215, like the non-autonomous gateway 215 of FIG. 5, in communicationwith a more detailed illustrative embodiment of a core node 265,according to various embodiments. As in FIG. 5, each non-autonomousgateway 215 includes multiple SMTSs 240, each in communication withmultiple L2 switches 247. Each L2 switch 247 is shown to be incommunication with a core node 265, so that the non-autonomous gateway215 is effectively in substantially redundant communication withmultiple core nodes 265. Further, in some embodiments, each core node265 is in communication with each other core node 265, either directlyor indirectly. For example, the core nodes 265 may be in communicationin a ring-like topology, a mesh-like topology, etc.

As discussed above, the non-autonomous gateways 215 communicate with thecore nodes 265 using layer-2 connectivity between one or more L2switches 247 in the non-autonomous gateways 215 and one or moremultilayer switches 250 in the core nodes 265. The illustrative firstcore node 265-1 is in communication with multiple non-autonomousgateways 215 via two multilayer switches 250. In various embodiments,the multilayer switches 250 are in communication with each other eitherdirectly or indirectly (e.g., via an gateway module 255).

In some embodiments, the gateway module 255 includes one or moreprocessing components for processing traffic received at the multilayerswitches 250. In one embodiment, the gateway module 255 includes atraffic shaper module 645. Embodiments of the traffic shaper module 645are configured to help optimize performance of the communications system600 (e.g., reduce latency, increase effective bandwidth, etc.), forexample, by delaying packets in a traffic stream to conform to one ormore predetermined traffic profiles.

The multilayer switches 250 may further be in communication with one ormore networks 605. The networks 605 may include the Internet 605 a, oneor more CDNs 605 b, one or more MPLS or VPLS networks 605 c, etc. Insome embodiments, the core node 265 includes an interface/peering node670 for interfacing with these networks 605. For example, an Internetservice provider or CDN service provider may peer with the core node 265via the interface/peering node 670.

Embodiments of the multilayer switches 250 process data by using one ormore processing modules in communication with the multilayer switches250. For example, as illustrated, the multilayer switches 250 may be incommunication with acceleration modules 650, provisioning modules 655,and/or management modules 660. Communications with some or all of thesemodules may be protected using components, like firewalls 665. Forexample, certain modules may have access to (and may use) privatecustomer data, proprietary algorithms, etc., and it may be desirable toinsulate that data from unauthorized external access. In fact, it willbe appreciated that many types of physical and/or logical security maybe used to protect operations and data of the core nodes 265. Forexample, each core node 265 may be located within a physically securedfacility, like a guarded military-style installation.

FIG. 6B shows embodiments of various modules in communication with oneor more multilayer switches 250, according to various embodiments. As inthe first core node 265-1 of FIG. 6A, FIG. 6B shows multilayer switches250 in communication with acceleration modules 650, provisioning modules655, and management modules 660. The multilayer switches 250 are incommunication with the provisioning modules 655 and management modules660 via a firewall 665. It is worth noting that the illustrated modulesare intended only to show one non-limiting embodiment. Many other typesof modules, units, groupings, configurations, etc. are possibleaccording to other embodiments.

In one embodiment, the acceleration modules 650 include beam-specificacceleration modules 602 and a failover module 604 which detects aconnection failure and redirects network traffic to a backup orsecondary connection. Embodiments of the acceleration modules 650provide various types of application, WAN/LAN, and/or other accelerationfunctionality. In one embodiment, the acceleration modules 650 implementfunctionality of AcceleNet applications from Intelligent CompressionTechnologies, Inc. (“ICT”), a division of ViaSat, Inc. Thisfunctionality may be used to exploit information from higher layers ofthe protocol stack (e.g., layers 4-7 of the OSI stack) through use ofsoftware or firmware operating in each beam-specific acceleration module602. The acceleration modules 650 may provide high payload compression,which may allow faster transfer of the data and enhances the effectivecapacity of the network. In some embodiments, certain types of data(e.g., real-time data, User Datagram Protocol (UDP) data traffic, etc.)bypass the acceleration modules 650, while types of data (e.g.,non-real-time data, Transmission Control Protocol (TCP) data traffic,etc.) are routed through the accelerator module 650 for processing. Forexample, IP television programming may bypass the acceleration modules650, while web video may be sent to the acceleration modules 650 fromthe multilayer switches 250.

In one embodiment, the provisioning modules 655 include a AAA/Radiusmodule 612, a DHCP/DNS module 614, a TFTP/NTP module 616, and a PKImodule 618. Embodiments of the AAA/Radius module 612 perform certaintypes of authentication and accounting functionality. For example, theAAA/Radius module 612 may implement functionality of an AuthenticationAuthorization Accounting (AAA) server, a Remote Authentication Dial-InUser Service (RADIUS) protocol, an Extensible Authentication Protocol(EAP), a network access server (NAS), etc. Embodiments of the DHCP/DNSmodule 614 implement various IP management functions, including DynamicHost Configuration Protocol (DHCP) interpretation, Domain Name System(DNS) look-ups and translations, etc. Embodiments of the TFTP/NTP module616 implement various types of protocol-based functions, including filetransfer protocols (e.g., File Transfer Protocol (FTP), trivial filetransfer protocol (TFTP), etc.), synchronization protocols (e.g.,Network Time Protocol (NTP)), etc. Embodiments of the PKI module 618implement various types of encryption functionality, includingmanagement of Public Key Infrastructures (PKIs), etc.

In one embodiment, the management modules 660 include anauthentication/accounting module 622, a terminal/shell module 624, apacket analysis module 626, an SNMP/Syslog module 628, etc. Embodimentsof the authentication/accounting module 622 implement variousauthentication and accounting functions that may be similar to ordifferent from those of the AAA/Radius module 612. For example, theauthentication/accounting module 622 may control certain billingfunctions, handle fair access policies (FAPs), etc. Embodiments of theterminal/shell module 624 implement various types of connectivity withindividual devices. Embodiments of the packet analysis module 626implement various packet analysis functions. For example, the packetanalysis module 626 may collect packet-level information and/orstatistics for use in certain types of accounting functions. Embodimentsof the SNMP/Syslog module 628 implement various network protocolmanagement and logging functions. For example, the SNMP/Syslog module628 may use the Simple Network Management Protocol (SNMP) to exposenetwork management information and the Syslog standard to log networkmessages.

FIG. 7A illustrates an alternative architecture of a core node 265-2, inaccordance with one embodiment of the present invention. Core node 265-2may be in communication with 1 to N non-autonomous gateways 215. Asdiscussed above, the non-autonomous gateways 215 communicate with thecore node 265-2 using layer-2 connectivity between one or more layer-2switches 247 in the non-autonomous gateways 215 and one or moremultilayer switches 250 a and 250 b in the core node 265-2. Theillustrative core node 265-2 is in communication with multiplenon-autonomous gateways 215 a-215 n via multilayer switches 250 a and250 b. In various embodiments, the multilayer switches 250 a and 250 bare in communication with each other either directly or indirectly(e.g., via a gateway module 255).

Embodiments of the multilayer switches 250 a and 250 b process data byusing one or more processing modules or interfaces in communication withthe multilayer switches 250 a and 250 b. For example, as illustrated,the multilayer switches 250 a and 250 b may be in communication withAAA/RADIUS 735 a, DHCP/DNS 735 b, TFTP/NTP 735 c, or PKI 735 d, througha firewall 665 and services interface 730. Furthermore, multilayerswitches 250 a and 250 b may be in communication with a provisioningmodule 755 through a firewall 665 b, a layer-2 switch 745, and amanagement interface 750. In addition to being in communication withprovisioning module 755, multilayer switches 250 a and 250 b may also bein communication with policy module 760 a, AAA/RADIUS 760 b,terminal/shell 760 c, IP flow information export (IPFIX), traffic and/orflow accounting and analysis 760 d, SNMP/syslog 760 e, and TFTP/NTP 760f. Communication with these modules may be restricted, for example,certain modules may have access to (and may use) private customer data,proprietary algorithms, etc., and it may be desirable to insulate thatdata from unauthorized external access. In fact, it will be appreciatedthat many types of physical and/or logical security may be used toprotect operations and data of the core node 265-2. For example, eachcore node 265 may be located within a physically secured facility, likea guarded military-style installation.

In a further embodiment, services interface 730 may be in communicationwith service 1 732 a to service N 732 n. Service 1 to service N may beany one of the services described above (i.e., AAA/RADIUS 745 a,DHCP/DNS 735 b, TFTP/NTP 735 c, PKI module 735 d, etc.), as well asother services provided in satellite networking environment.Furthermore, any number of services may be provided (i.e., 1-N number ofservices).

In one embodiment, AAA/Radius module 760 b may implement thefunctionality of AAA/Radius module 612, DHCP/DNS module 735 b mayimplement the functionality of DHCP/DNS module 614, TFTP/NTP module 735c may implement the functionality of TFTP/NTP module 616, SNMP/Syslogmodule 760 e may implement the functionality of SNMP/Syslog module 628,terminal/shell module 760 c may implement the functionality ofterminal/shell module 624, and PKI module 735 d may implement thefunctionality of PKI module 618. In a further embodiment, policy module760 a may control certain billing functions, handle fair access policies(FAPs), etc.

In an alternative embodiment, FIG. 7B illustrates traffic shaper module645 operating separately from gateway module 255. In this configurationtraffic shaper module 645 may be locally or remotely located fromgateway module 255, and may communicate directly with multilayerswitches 250 a and 250 b, or with gateway module 255.

Accordingly, core node 265 is configured to internally handle variousservices and functionality. Turning now to FIG. 7C, which illustratesone embodiment of a core-based network architecture 700-c, implementinga non-routed ground segment network 220-a which includes core nodes 265.In one embodiment, each core node 265 a-d is connected to every othercore node, and each core node 265 a-d is connected to a non-autonomousgateway 215 a-d, respectively. This configuration is merely for thepurposes of explanation, and it should be noted that any number of corenodes or non-autonomous gateways may be used. Also, core nodes may beindirectly connected to other core nodes, core nodes may be connected toother core nodes through one or more non-autonomous gateway, etc.

Such a network configuration provides significant benefits. For example,service and/or resource specific failure at a core node, or completefailure of a core node is able to be redundantly managed by one or moreof the other core nodes. Assuming, for the purpose of explanation, thatcore node 265 a services non-autonomous gateway 215 a, core node 265 bservices non-autonomous gateway 215 b, and so forth. If for example,DHCP service at core node 265 b fails, then DHCP service requests fromthe customers connected with non-autonomous gateway 215 b would beserviced through core node 265 d, without the customers noticing anychange. For example, their IP address, their session, etc. would remainthe same. Furthermore, the other services provided by core node 265 b(e.g., DNS, acceleration, PKI, etc.) would still be handled by core node265 b, and only the failed service would be diverted to core node 265 d.

Such a service specific redundancy scheme is possible by this networkconfiguration, in part, because of the end-to-end layer-2 connectivity,the placement of the core nodes, and structure and configuration of thecore nodes 265. For example, if the network did not have end-to-endlayer-2 connectivity, then such redundancy would not be possible. If thepackets were routed (i.e., layer-3 or above), or virtually switched(i.e., MPLS), then once a packet went from core node 265 b to core node265 d, the MAC header of the packet would be altered, and as such thenetwork (i.e., the LAN, subnet, etc.) of the packet would change.Accordingly, the ability to provide service through the new core node(e.g., core node 265 d) would be lost.

Similarly, if a core node completely fails or the connection (e.g.,fiber cable) between a core node and a non-autonomous gateway fails,then all of the operations of the failed core node are able to beassumed by (or diverted to) one or more other core nodes. For example,if the connection between non-autonomous gateway 215 a and core node 265a is cut or damaged, then core node 265 c may provide the servicespreviously provided by core node 265 a to non-autonomous gateway 215 a.In one embodiment, in both examples the core node assuming the failedservice in response to a complete failure may be notified of the failureby, for example, time-to-live (TTL) packets, acknowledgment packets,etc. If the core node's functions fall below a threshold, another corenode may be triggered to assume servicing of the failed service (orservices).

Furthermore, such a network configuration is configured to allow sharingof resources among the core nodes. For example, one or more resources atone code node may be over-burdened, while other core nodes may berunning under capacity. In such a situation, some or all of the servicesfrom the over-burdened core node may be diverted to one or more othercore nodes. As such, the usage of all cores may be distributed in orderto maximize core node resource use and avoid a core node from being overcommitted.

It should be noted that any available path within non-routed groundsegment network 220-a may be used. For example, it may be more efficientor necessary for a failed service at core node 265 c to be handled bycore node 265 b, by passing though non-autonomous gateway 215 d. Assuch, network 700-c provides completely dynamic paths among the corenodes 265 and non-autonomous gateways 215. Furthermore, within network700-c, any service can be provided to any customer by any core at anytime. In one embodiment, core node connectivity may be fully meshed atlayer-2 using VPLS.

In one embodiment, because core node 265 is configured to provideend-to-end layer-2 connectivity across a network, core node 265 is ableto more easily peer with one or more public or private networks. Forexample, a public or private network may connect with non-autonomousgateway 215 d. The customers connected to non-autonomous gateways 215a-c can receive the content from the peering node connected tonon-autonomous gateway 215 d, as though the peering node was connecteddirectly to their respective non-autonomous gateways 215 a-c. This isdue, in part, to the end-to-end layer-2 connectivity and inter-nodeconnectivity. As such, the content provided by the peering node tocustomers connected with non-autonomous gateway 215 d is also providedto each of the other customers connected with non-autonomous gateways215 a-c. As such, peering at one node that is geographically dispersedfrom other nodes (or gateways) may be able to provide access to thepeered network from the other nodes or gateways. For example, by peeringwith a network in Dallas, network 700-c has access to the peered networkfrom Denver (or anywhere else with network 700-c).

For example, a peering node in Dallas connected to a non-autonomousgateway 215 in Dallas can provide their content to customers in SanFrancisco (e.g., non-autonomous gateway 215 a), Denver (e.g.,non-autonomous gateway 215 b), Salt Lake (e.g., non-autonomous gateway215 c), by only connecting through a single drop point (i.e., Dallas).As such, a peering node providing content significantly increases thenumber of customers, without adding additional drop points. This isparticularly useful in a peering context because in order for a peeringrelationship to exist, the two networks need to be “peers” (i.e., berelatively equal in content and customer base). Network 700-csignificantly increases the number of customers that the entityimplementing network 700-c can represent to the potential peer, thusincreasing the likelihood of developing a peering (or equal)relationship.

Similar to a peering node, network 700-c may connect with contentservice network (CSN) and/or a content delivery network (CDN) 605through one or more gateways 215. Like a peering relationship, CSN/CDN605 provides content and services to a network provider, and typicallysuch CSN/CDNs 605 are located at high traffic areas (e.g., New York, SanFrancisco, Dallas, etc.). Moving these CSN/CDNs 605 to more remote ofmore locations is often not economical. Accordingly, network 700-callows CSN/CDN 605 to connect at any gateway 215 or core node 265, andnot only provide the content and/or services to the customers at theconnected core node 265 or non-autonomous gateway 215, but to customerswithin the entire network 700-c connected to all non-autonomous gateways215 and core nodes 265. Thus, the CSN/CDN 605 can connect at one droppoint, and provide content to all customers within network 700-c.

This, in part, is made possible by the end-to-end layer-2 connectivityof network 700-c. If the network was routed, then the customers notdirectly connected to the gateway or core node at the drop point for theCSN/CDN 605, are difficult to be on the same network and would not beable to receive the content and services. Furthermore, the redundancyscheme of network 700-c provides a sufficient amount redundancy toaccommodate for such a large number of customers. Without the redundancyscheme of network 700-c, CSN/CDN 605 would not be able to besufficiently supported.

Additionally, network 700-c is capable of utilizing out-of-band failover networks for additional redundancy (e.g., out of band (00B)network). Again, the out-of-band network can only be connected to onenon-autonomous gateway 215 or core node 265, but still provide theredundancy to any part of network 700-c. As such, network 700-c needonly connect to the out-of-band network at one location in order to gainthe benefit of the out-of-band network throughout the entire network700-c.

Furthermore, it should be noted that the configuration illustrated inFIG. 7C should not be construed as limiting, and any number ofvariations to the network architecture may be used. For example, anon-autonomous gateway may be connected to two core nodes and no othernon-autonomous gateways. Alternatively, the core nodes may note beinterconnected and/or a non-autonomous gateway may be placed between twocore nodes. As such, any number of variations may be implemented.

It is worth noting that the functionality of the various modules isdescribed as occurring within one or more core modules 265, and the coremodules 265 are in communication with a distributed network ofnon-autonomous gateways 215 and/or other nodes. While this type ofdistributed non-routing networking may be preferred in manyenvironments, it may be difficult (e.g., not cost-effective ortechnologically inefficient) or impractical for a gateway to communicatewith a core node 265. As such, it may be desirable in some environmentsto implement a so-called autonomous gateway having at least some of thecombined functionality of a non-autonomous gateway 215 and a core node265.

FIG. 8 shows an embodiment of an autonomous gateway 815, according tovarious embodiments. In some embodiments, the autonomous gateway 815includes one or more SMTSs 240, which may be implemented substantiallyas the SMTSs 240 of the non-autonomous gateway 215 of FIG. 2. The SMTSs240 may be in communication with one or more multilayer switches 250.The multilayer switches 250 may be in communication with a gatewaymodule 255 and an interface/peering node 670. The interface/peering node670 may be in communication with one or more other networks 605. It isworth noting that the gateway module 255 may include other functionalityin certain embodiments. For example, the illustrated embodiment includesa traffic shaper module 645. In other embodiments, the traffic shapermodule 645 may be implemented differently or as part of a differentcomponent. The multilayer switches 250 may be configured to process datausing one or more modules. For example, the multilayer switches 250 maybe in communication with acceleration modules 650, provisioning modules655, services module 730, and/or management modules 660, for example,through one or more firewalls 665. It will be appreciated that, unlikethe typical gateway 115 of FIG. 1, in accordance with aspects of thepresent invention, embodiments of the autonomous gateway are able toimplement some of the enhanced (e.g., Layer-2 connectivity-enabled)functionality of the non-autonomous gateways 215 and core nodes 265.

In one embodiment, autonomous gateway 815 is configured to operateautonomously or separately from other gateways and/or core nodes. Forexample, using services module 730, acceleration modules 650,provisioning modules 655, and/or management modules 660, autonomousgateway 815 is able to completely manage requests received through SMTSs240 and multilayer switches 250 a and 250 b. Furthermore, sincemultilayer switches 250 a and 250 b are equipped to handle requests atboth layer-2 and layer-3, autonomous gateway 815 is not limited in thesame ways as gateway 115.

In one embodiment, services module 730 may include services, such as,AAA, RADIUS, DHCP, DNS, TFTP, NTP, PKI, etc. Furthermore, managementmodules 660 may include billing, terminal, shell, IP flow informationexport (IPFIX), traffic and/or flow accounting and analysis, SNMP,syslog, etc. Accordingly, autonomous gateway 815 is equipped to functionas a “stand-alone” entity, locally (or pseudo-locally) providingservices and management to CPEs.

FIG. 9 shows an embodiment of a satellite communications system 900 thatdistributes autonomous gateways 815 and non-autonomous gateways 215across a number of geographically dispersed regions 905, according tovarious embodiments. In one embodiment, a first geographic region 905 a,a second geographic region 905 b and a sixth geographic region 905 frepresent environments where it is not cost-effective to providecommunications with core nodes 265. As such, these geographic regions905 are illustrated as having autonomous gateways 815. For example,autonomous gateways 815 may be used in island regions, geographicallyremote regions, regions with particular types of topologies (e.g., largemountain ranges), etc.

In contrast to the above-mentioned regions (geographic regions 905 a,905 b, and 905 f), a third geographic region 905 c, a fourth geographicregion 905 d, and a fifth geographic region 905 e indicate regions whereit is cost-effective to implement a core-based non-routed ground segmentnetwork 220. As illustrated, each non-autonomous gateway 215 is eitherdirectly or indirectly in communication with at least one core node 265(e.g., typically two core nodes 265). Other components may also beincluded in the non-routed ground segment network 220. For example,additional switches 910, optical cross-connects 920, etc. may be used.Further, while the non-routed ground segment network 220 is configuredto provide point-to-point layer-2 connectivity, other types ofconnectivity may also be implemented between certain nodes. For example,one or more VPLS networks may be implemented to connect certain nodes ofthe non-routed ground segment network 220.

In various embodiments, core nodes 265 may be located on a new orexisting fiber run, for example, between metropolitan areas. In someconfigurations, the core nodes 265 may be located away from the majorityof spot beams (e.g., in the middle of the country, where much of thesubscriber population lives closer to the outsides of the country). Inalternative embodiments, core nodes 265 may be located near the majorityof spot means. Such spatial diversity between code nodes and subscriberterminals may, for example, facilitate frequency re-use of betweenservice beams and feeder beams. Similarly, non-autonomous gateways 215may be located to account for these and/or other considerations.

It is worth noting that, in the non-routed ground segment network 220,twelve gateways (e.g., including both non-autonomous gateways 215 andautonomous gateways 815) are illustrated. If all were implemented asautonomous gateways 815, the topology may require twelve gatewaymodules, routers, switches, and other hardware components. Further,various licensing and/or support services may have to be purchased foreach of the autonomous gateways 815. In some cases, licensingrequirements may dictate a minimum purchase of ten thousand licenses foreach gateway module, which may require an initial investment into120-thousand licenses from the first day of operation.

Using aggregated functionality in one or more core nodes 265, however,may minimize some of these issues. For example, the non-routed groundsegment network 220 includes four core nodes 265, each having a gatewaymodule, and only three of the twelve gateways are autonomous gateways815. As such, only seven gateway modules may be operating on thenon-routed ground segment network 220. As such, only seven instances ofeach core networking component may be needed, only seven licenses may beneeded, etc. This may allow for a softer ramp-up and other features.

It will be appreciated that there are many types of functionality thatmay be supported and/or enabled by facilitating persistent layer-2connectivity throughout the non-routed ground segment network 220. Oneset of functionality includes the provision of layer-2 extensionservices, through which one or more services may be applied to trafficacross the non-routed ground segment network 220, for example, byassociating the service with a particular virtual tagging tuple 375. Asdiscussed above with reference to FIG. 3, virtual tagging tuples 375 maybe used effectively to designate certain types of traffic in a way thatpersists across the non-routed ground segment network 220.

FIG. 10 shows an embodiment of a portion of a communications system 1000configured to facilitate layer-2 extension services, according tovarious embodiments. The communications system 1000 may be a portion ofthe communications system 900 of FIG. 9. As illustrated, a serviceprovider 1010 interfaces with (e.g., establishes layer-2 connectivitywith) a non-autonomous gateway 215 in a first geographic region 905 a.The service provider 1010 is assigned, or otherwise associated with, atleast one virtual tagging tuple 375 (e.g., or at least one element of avirtual tagging tuple 375).

It will be appreciated from the preceding description that, by virtue ofplugging into a single non-autonomous gateway 215, embodiments of thenon-routed ground segment network 220 can provide layer-2 connectivitybetween the service provider 1010 and any other node of the non-routedground segment network 220. Further, by being associated with at least aportion of a virtual tagging tuple 375, the service provider 1010 canextend its service offerings to customers 1020 serviced by any node ofthe non-routed ground segment network 220 without having to build out alayer-2 infrastructure in other locations. For example, by plugging intothe non-autonomous gateway 215 in the first geographic region 905 a, theservice provider 1010 may be able to service customers 1020 in asubstantially remote third geographic region 905 c. As such, customers1020 may experience a service offering from the service provider 1010substantially as if the customers were connected with the serviceprovider 1010 via a local subnet.

While the service provider 1010 is shown interfacing with the non-routedground segment network 220 at a non-autonomous gateway 215, the serviceprovider 1010 may alternatively interface with the non-routed groundsegment network 220 at any other node where the layer-2 connectivity isaccessible. For example, if a service provider 1010 already has aninfrastructure built out close to a core node 265 in Arizona, theservice provider 1010 can connect to that core node 265 to servicecustomers 1020 via a non-autonomous gateway 215 in New York, even withno layer-2 infrastructure in New York.

For example, say an enterprise customer purchases the identifier “205”for use as the first element of a virtual tagging tuple 375. In oneembodiment, all enterprise traffic is designated at layer 2 by a tupleof the form “(205, XXX),” where “XXX” indicates a location. For example,data tagged anywhere in the non-routed ground segment network 220 as“(205,100)” is associated with the enterprise customer and anon-autonomous gateway 215 at location “100” (e.g., Kansas), while datatagged anywhere in the non-routed ground segment network 220 as“(205,128)” is associated with the enterprise customer and anon-autonomous gateway 215 at location “128” (e.g., New Mexico).

In another embodiment, a DSL service provider 1010 in Colorado desiresto provide DSL services to customers 1020 in New York, where it has nolayer-2 infrastructure. The DSL service provider 1010 is assigned aparticular tuple designation. The DSL service provider 1010 then plugsinto the non-routed ground segment network 220 at a node in Denver. AllDSL traffic from that provider, all over the non-routed ground segmentnetwork 220, is tagged with the assigned virtual tuple designation. Assuch, DSL customers 1020 in New York may substantially immediately beprovided with DSL services that appear to the customers to be “local.”

In still another embodiment, all traffic for an Internet serviceprovider 1010 is designated at layer 2 by a tuple of the form “(205,XXX, YYY),” where “XXX” indicates a location and “YYY” designates aservice offering. For example, data tagged anywhere in the non-routedground segment network 220 as “(205, 100, 5D2)” is associated with theInternet service provider 1010, a non-autonomous gateway 215 at location“100” (e.g., Kansas), and a certain type of traffic shaping designatedby “5D2”; while data tagged anywhere in the non-routed ground segmentnetwork 220 as “(205, 100, 083)” is associated with the Internet serviceprovider 1010, the non-autonomous gateway 215 at location “100,” and aVPLS network. Of course, any other type of particular service offeringmay be designated (e.g., (e.g., multicasting, VPN, MPLS, VLAN,enterprise caching, etc.). In other embodiments, the virtual taggingtuples 375 may have other numbers of elements, other types ofdesignations may be used, single elements may designate multiplelocations or services, etc.

FIG. 11 shows an illustrative flow diagram of a method 1100 ofimplementing layer-2 connectivity within a satellite ground segmentbackhaul network. At process block 1105, data packets from one or moresatellites may be transmitted to an access point. In one embodiment, anaccess point may be a base station, a gateway, a combination of basestations, etc.

At process block 1110, the data packets may be received at the accessnode from the one or more satellites at layer-1 of the OSI-model.Accordingly, at process block 1115, virtual tagging tuples within thelayer-2 headers of the data packets may be generated. In one embodiment,the tuples may, at least, include an entity and a location designation.At process block 1120, the tagged packets may then be transmitted fromthe access point to switches and other destinations within the backhaulnetwork.

For example, if a virtually tagged packet is received at a switch(process block 1125), then the switch may transmit each of the virtuallytagged packets to an entity and location based on the tuple information(process block 1130). Accordingly, the virtually tagged packets are ableto be transmitted across the backhaul network at layer-2, thus providingsignificant benefits to the backhaul network.

FIG. 12 shows an illustrative flow diagram of a method 1200 ofimplementing access node/gateway to access node/gateway layer-2connectivity within a backhaul ground segment network connected to oneor more satellites. At process block 1205, data packets may betransmitted form a first satellite to a first base station. The firstbase station may then generate virtual tagging tuples to include in thelayer-2 header (process block 1210).

Furthermore, the first base station then transmits the virtually taggedpackets to a first switch (process block 1215), and the first switchtransmits the packets to a second switch (process block 1220). Then, atprocess block 1225, the second switch transmits the packets to a secondbase station which determines, based on the virtual tagging tuple, theentity and destination of the packets (process block 1230).

FIG. 13 shows a flow diagram of a method 1300 for providing layer-2extension services across a non-routed ground segment network, accordingto various embodiments. The method 1300 begins at block 1305 byproviding a Layer-2 interface between a node of a non-routed groundsegment network and a service provider. At block 1310, a layer-2 virtualtagging tuple is assigned to the service provider. Service providertraffic is received at any node of the non-routed ground segment networkat block 1315. At block 1320, the service provider traffic is taggedwith the appropriate virtual tagging tuple. The tagged service providerdata is then switched, at block 1325, through the non-routed groundsegment network according to the virtual tagging tuple.

Aspects of the invention include providing mobility among multiplesatellite beams. Particularly, a mobile device (or client) is able tomove among satellite and maintain the same consistent IP address.Furthermore, the mobile device is able to remain within the same network(i.e., LAN, subnet, etc.) while moving through coverage of multiplesatellite beams. Aspects of the invention are realized, in part, due toend-to-end layer-2 connectivity throughout the ground segment network.

FIG. 14 shows a block diagram of a system 1400 for implementing mobilityacross satellite spot beams, according to various embodiments of theinvention. In one embodiment, system 1400 may include core nodes 265 aand 265 b in communication with the Internet 605 a, CND/CSN 605 b andMPLS/VPLS networks 605 c. Core nodes 265 a and 265 b are incommunication together at layer-2 of the OSI model. Furthermore, corenode 265 a is in communication, at layer-2, with non-autonomous gateway215 a and non-autonomous gateway 215 b, and core node 265 b is incommunication, at layer-2, with non-autonomous gateway 215 c.

In a further embodiment, each of non-autonomous gateways 215 a-c servicespot beams at locations 1410, 1411, and 1412, respectively. Mobiledevice 1430 is in communication with non-autonomous gateway 215 a atlocation 1410. In one embodiment, mobile device 1430, upon connectingthrough a spot beam to non-autonomous gateway 215 a is assigned an IPaddress, and the IP address is associated with a local area network(LAN). Mobile device 1430 executes a number of applications (e.g., aninternet browser, and email client, etc.), enterprise applications (VPN,exchange, etc.), etc. While the applications are being executed onmobile device 1430, application sessions are established, and relianceon the assigned IP address is necessary by these applications. Further,in the event that connectivity is lost by the mobile device 1430, ormobile device 1430's IP address is changed, then applicationconnectivity and the session would be lost.

Assuming now that mobile device 1430 is travelling in an airplane (in anautomobile, on a train, on a ship, etc), and mobile device 1430 hasestablished a VPN session (or other application). As the airplanetravels from location 1410 to location 1411, the spot beam servicingmobile device 1430 changes, and accordingly the non-autonomous gatewayservicing the spot beam changes from non-autonomous gateway 215 a tonon-autonomous gateway 215 b. As such, in order to maintain the same IPaddress, connectivity, the VPN session (in this example), etc., then ahandoff of the IP address for mobile device 1430 occurs.

In one embodiment, the overlap of spot beam coverage at location 1410and 1411 is detected and the eminent transition of mobile device 1430,and as such from coverage under the first spot beam and the second spotbeam is detected. Once the eminent transition is detected andidentified, non-autonomous gateway 215 a sends a “handoff” message tocore node 265 a, and then from core node 265 a to non-autonomous gateway215 b. Each hop is at layer-2 of the OSI model and the messages are atlayer-3 and above, which allows the layer-3 protocol to be IP, DECNet,AppleTalk, or the like. As such, each of non-autonomous gateway 215 a,core node 265 a, and non-autonomous gateway 215 b are able to be on thesame network (i.e., same subnet, same LAN, etc.).

Accordingly, as mobile device 1430 move to location 1411, non-autonomousgateway 215 b is transitioned to maintaining connectivity for mobiledevice 1430. Thus, connectivity is maintained, the same IP address ismaintained, and so forth. In a further embodiment, even if mobile device1430 continues to travel to location 1412, which is covered by a spotbeam serviced by non-autonomous gateway 215 c. Connectivity of mobiledevice 1430 is still maintained. Non-autonomous gateway 215 c is incommunication with core node 265 b, thus IP address and connectivity ofmobile device is still able to be maintained.

In this situation, once it is determined that mobile device 1430 isgoing to transition from the spot beam servicing location 1411 to thespot beam servicing location 1412, non-autonomous gateway 215 b sends anotification to non-autonomous gateway 215 c. The notification is sentat layer-3 (whereas the user traffic is sent at layer-2) fromnon-autonomous gateway 215 b to core node 265 a, core node 265 a to corenode 265 b, and then from core node 265 b to non-autonomous gateway 215c. Again, at no time during the handoff is connectivity to mobile device1430 lost, or is the IP address of mobile device 1430 changed. Thus,system 1400 is configured to provide end-to-end continual connectivity,IP address, and session persistence across spot beams in a satellitenetwork.

Turning now to FIG. 15, which illustrates a system 1500 for providingmobility access across satellite spot beams, according to one embodimentof the present invention. In one embodiment, system 1500 includes amobile device 1430 in communication with satellite 105. Mobile device1430 is moving, for example, from west to east; however, it should benoted that mobile device 1430 could be moving in any direction. In oneembodiment, mobile device 1430 is a Smartphone, a PDA, a laptopcomputer, a mobile computer, a cellular telephone, etc. Furthermore,mobile device 1430 may be travelling on a train, a plane, andautomobile, etc.

Satellite 105 provides mobile device 1430 with network connectivity at afirst location through a first spot beam 1410. Satellite 105 is furtherconfigured to provide mobile device 1430 with network connectivity at asecond location through spot beam 1411. Accordingly, as mobile device1430 moves from location to location, satellite 105 is able to providemobile device 1430 with network connectivity at satellite 105's variousspot beams. It should be noted that while only two spot beams are shown,but many more spot beams and many more locations may be present, but forexplanatory purposes and ease of understanding, only two spot beams havebe shown in FIG. 15.

Once mobile device 1430 has established connectivity with satellite 105,mobile device 1430 receives session and/or IP information. For example,mobile device 1430 is granted a IP address, which is likely a subnetaddress. In a typical system, when mobile device 1430 moves from thecoverage of spot beam 1410 to spot beam 1411, such session informationwould be lost, and a new session (or a new IP address) would beestablished at spot beam 1411. Thus, mobile device 1430 would loseconnectivity, change IP addresses, and would no longer be on the samenetwork (i.e., subnet, LAN, etc.) while the “handoff” from spot beam1410 to spot beam 1411 occurs.

According to one embodiment of the present invention, such a loss ofconnectivity as well as IP address and session information is avoidedusing the layer-2 connectivity between non-autonomous gateway 215 a,non-autonomous gateway 215 b, core node 265 a and core node 265 b. Inone embodiment, mobile device 1430 is travelling, for example, in atrain from New York to San Francisco. For simplicity's sake, only twospot beams have been shown, but in reality there would likely be manymore spot beams between San Francisco and New York. As mobile device1430 travels from the first location to the second location it becomenecessary for a handoff to occur from spot beam 1410 to spot beam 1411.

At that point, session and IP information stored at non-autonomousgateway 215 a is transmitted to core node 265 a and then from core node265 a to core node 265 b. Then, the session and IP information istransmitted from core node 265 b to non-autonomous gateway 215 b.Furthermore, the connectivity the entire way from non-autonomous gateway215 a to non-autonomous gateway 215 b is at layer-2 of the OSI model. Assuch, mobile device 1430 is able to move from the first location to thesecond location without any change in connectivity. The handoff iscompletely transparent to mobile device 1430. Mobile device 1430's IPaddress remains the same, no break in connectivity occurs, applicationsessions are maintained, etc.

Furthermore, satellite 105 establishes a connection with mobile device1430 at the second location using spot beam 1410, the sessioninformation from mobile device 1430's session through spot beam 1411 ismaintained for the connection at the second location with spot beam1411. Accordingly, mobile device 1430 is unaware that any handoff hasoccurred, and all session connectivity and information is maintained.

Referring now to FIG. 16, which illustrates a method 1600 of providingmobility access across satellite spot beams, according to one embodimentof the present invention. At process block 1605, network access to amobile device through a first spot beam at a first location is provided.The satellite is further in communication with at least a first andsecond gateway, which are in turn in communication with at least a firstand second core node.

At process block 1610, an indication is received that the mobile deviceis moving from the first location to a second location, where the secondlocation is serviced with a second spot beam. Accordingly, at processblock 1615, the first gateway connects with a second gateway at alayer-2 through the first and second core nodes. Due to the fact thatthe connectivity from the first gateway to the first core node, thefirst core node to the second core node, and then the second core nodeto the second gateway is at layer-2, and the mobile device is able tomaintain the same IP address through the handoff and any applicationand/or session information (process block 1620).

Thus, at process block 1625, the mobile device at the second locationthrough the second spot beam established access to the network with thesame IP and/or session of the mobile device while at the first locationconnected to the first spot beam. Hence, no connectivity break, no lossof session, no loss IP information, etc. occurs.

Aspects of the invention relate to having one gateway which services twoor more satellites. A further embodiment includes multiple satellitesbeing serviced by multiple gateways which are in communication with corenodes within a non-routed ground segment network. Furthermore, analternative embodiment includes multiple satellites services by multiplegateways which are in communication with multiple core nodes.

Turning now to FIG. 17, which illustrates a network 1700 forimplementing layer-2 connectivity for multiple satellites with a singlegateway, according to various embodiments of the invention. In oneembodiment, network 1700 may include a core non-routed ground segmentnetwork 220 in communication with a non-autonomous gateway 215. Network1700 may further include a satellite 105 a and 105 b each providing aspot beam 1710 a and 1710 b, respectively. Client device 1730 a may beserviced by spot beam 1710 a and client device 1730 b may be serviced byspot beam 1710 b.

Furthermore, non-autonomous gateway 215 may be in communication withboth satellites 105 a and 105 b. In one embodiment, non-autonomousgateway 215 may include one antenna (or other suitable transmissiondevice) configured to send and receive transmissions to and fromsatellite 105 a and another antenna configured to send and receivetransmissions to and from satellite 105 b. It should be noted thatadditional antennas may be included at non-autonomous gateway 215 inorder to service any number of satellites. With such a configurationclient device 1730 a and client device 1730 b are able to exist on thesame private network (i.e., the same subnet, the same LAN, etc.).

This is, in part, due to the fact that services offered to client device1730 a and client device 1730 b are able to be provided through the samenon-autonomous gateway 215 and non-routed ground segment network 220, atlayer-2. For example, DHCP service provided by network 220 to clientdevice 1730 a passes through essentially the same network path asservice to client device 1730 b. The only difference is the base stationwithin the SMTS servicing client device 1730 a would be different fromthe base station servicing client device 1730 b, and the satellitesservicing each client device would also be different. However, sincecommunications at each of the points within the network are at layer-1(i.e., at the satellites) or layer-2 (i.e., at the getaways and corenodes), client devices 1730 a and 1730 b are able to be on the sameprivate network, even though client device 1730 a may be in Boston andclient device 1730 b may be San Francisco.

Furthermore, if client device 1730 a travels to the coverage of spotbeam 1710 b, client device 1730 a is still able to maintain the same IPaddress, network session, connectivity, etc. Thus, such a networkconfiguration as in network 1700 provides transparent and seamlesssatellite mobility for client devices accessing network 1700.

In a further embodiment, satellite 105 a may be a first type ofsatellite and satellite 105 b may be a second type. For example, thefirst type may be a KA-band satellite, and the second type may be aKU-band satellite. However, other types of satellites may be used.

Referring next to FIG. 18, which illustrates a network 1800 forimplementing layer-2 connectivity for multiple satellites with multiplegateways, according to various embodiments of the invention. In oneembodiment, network 1800 may include satellites 105 a and 105 bproviding service to a client device 1830 a through a spot beam 1810 aand a client device 1830 b through spot beam 1810 b, respectively.Network 1800 may further include a non-autonomous gateway 215 a and anon-autonomous gateway 215 b in communication with a non-routed groundsegment network 220 through core nodes 265 a and 265 b, respectively.

According to the configuration of network 1800, client devices 1830 aand 1830 b are able to be connected to the same private network. Inother words, client device 1830 a and client device 1830 b are able tobe assigned IP addresses on the same subnet or LAN. Accordingly, ifclient device 1830 a travels from spot beam 1810 a to spot beam 1810 b,client device 1830 a is able to keep the same IP address, and the switchbetween spot beams (i.e., the switch between satellites 105 a and 105 b)is transparent and seamless to client device 1830 a. As such, multiplesatellites may be interconnected using the same private network, thusexpanding satellite coverage and service beyond an individual provider.Additionally, worldwide coverage for customers may also be achieved.

Furthermore, redundancy among core nodes 265 a and 265 b also providessatellites 105 a and 105 b with redundancy. For example, since core node265 b services satellite 105 b, if core node 265 b was to fail, all ofthe service to satellite 105 b's customers would also fail. However,since core nodes 265 a and 265 b are connected at layer-2 and areconfigured to provide fail-over redundancy and resource sharing, even ifcore node 265 b fails, core node 265 a is able to maintain service forsatellite 105 b's customers.

Turning now to FIG. 19, which illustrates a network 1900 forimplementing layer-2 connectivity for multiple satellites with multiplegateways and multiple cores, according to various embodiments of theinvention. In one embodiment, network 1900 may be configured similar tonetwork 1800; however, network 1900 includes two non-routed groundsegment networks 220 a and 220 b in communication via connection 1905.In one embodiment, connection 1905 may be at layer-3, a VPN, a VPLS,etc. In a further embodiment, networks 220 a and 220 b may provideservice to separate providers (i.e., two different satellite serviceproviders).

As described above, aspects of the invention include implementing nodeswhich provide intelligence and functionality (e.g., services, etc).Furthermore, the nodes are interconnected with gateways which provideconnectivity to satellites. As such, enterprises, content distributionnetworks (CDNs), etc. are able to connect to any node or other point inthe network (including gateways), and seems like being plugged in to anyother node or point in the network.

FIG. 20 illustrates a flow diagram describing a method 2000 ofimplementing redundancy among core nodes, in accordance with embodimentsof the present invention. At process block 2005, services, at layer-2,are provided to a first set of subscribers by a first core node though afirst non-autonomous gateway. At process block 2010, services, atlayer-2, are provided to a second set of subscribers by a second corenode though a second non-autonomous gateway.

At process block 2015, the second core node receives an indication thata service provided by the first core node has failed, or the core nodehas completely failed. At process block 2020, in response to the secondcore node receiving the failure notification, the second core nodebegins to provide the failed service (or services) to the first set ofsubscribers. The hand-off is seamless and the first set of customers areable to maintain the same IP address, session, etc. The service (orservices) is merely provided by another core node, without the first setof subscribers being aware of the change.

In a further embodiment, even without a failure by one of the corenodes, one or more services may be diverted to another core node basedon load at the core node. For example, the first set of subscribers maybe using a more resources than the second set of subscribers. As such,the first core node is significantly more burdened than the second corenode. One or more services provided to the first set of subscribers maybe diverted to the second core node in order to avoid the first corenode running out of capacity, or in order to more efficiently utilizethe entire capacity of the cores, collectively. The hand-off betweencore nodes is seamless and unnoticed by the subscribers.

FIG. 21 shows a block diagram of a network 2100 for implementingacceleration through a tunnel, according to various embodiments of theinvention. In one embodiment, network 2100 may include CPE 160 incommunication with user terminal (UT) 130. In one embodiment, CPE 160may initiate a network request(s) and transmit the request to UT 130.The network request may be a web request (e.g., a browser request forweb content, a webpage request, a file request from an FTP server, astreaming video request, etc.). The request may be included as thepayload of a packet 2105 a.

In multiple embodiments, packet 2105 a may also include a packet header.The packet header may include a MAC header, an IP header, and a TCPheader. Each of the MAC, IP, and TCP headers may include a source (SRC)and a destination (DST). In this example, the request is for a website(i.e., XYZ.com) and in packet 2105 a, the MAC SRC is CPE 160 and MAC DSTis UT 130. The IP header SRC is CPE 160 and DST is XYZ.com (i.e., Web).The TCP header SRC and DST indicate port assignments (e.g., port 80 forweb traffic, port 21 for FTP traffic, etc.).

Further, packet 2105 a is transmitted via satellite 105 to SMTS 240 innon-autonomous gateway 215. Prior to transmission, UT 130 changes packet2105 a to that of packet 2105 b. The Internet Protocol ConvergenceSublayer (IP-CS) protocol header (or alternatively Ethernet ConvergenceSublayer Eth-CS) is used to modify the MAC header and the payload isreplaced with an acceleration protocol (e.g., Intelligent CompressionTechnology (ITC) transport protocol (ITP)). A UDP header may be added tothe port designations for the SRC and DST. Such a protocol is configuredto allow for acceleration/compression techniques to be performed on thepayload of the packet. The details of such compression and accelerationare beyond the scope of this patent. Suffice it to say, a number ofvarious compression algorithms, acceleration techniques, etc. may beused. For example, byte caching, prefetching, multicasting, deltacoding, etc. may be used by the acceleration protocol.

As such, because of the compression and other acceleration techniques,the amount/size of data transmitted over satellite 105 and/or betweennon-autonomous gateway 215 and core node 265, can be greatly reduced.

Conversely, a network provider would be unable to efficiently andeffectively service customers if compression and acceleration were notpossible over a long delay satellite network. Furthermore, compressionallows valuable satellite bandwidth to be freed up, allowing the networkoperator to either offer more bandwidth to existing customers or add newcustomers on the network. Accordingly, network 2100 provides a networkprovider with the ability to compress and accelerate network traffic.

Once packet 2105 b is received at SMTS 240, packet 2105 b is altered toresemble packet 2105 c. In one embodiment, a packet encapsulationprotocol tunnel is established. In this example, the tunnel extends fromSMTS 240 to gateway module 255. Other tunnels may be used and the tunnelbeginning point and end point may be different. Furthermore, many packetencapsulation protocols may be used. For example, the Generic RoutingEncapsulation (GRE) protocol, IP in IP protocol (IP-IP), etc. may beused. In this example, the GRE protocol is shown; however, IP-IP or anyother packet encapsulation protocol could have been shown.

For example, GRE is a tunneling protocol that can encapsulate a widevariety of network layer protocol packet types inside IP tunnels,creating a virtual point-to-point link to various brands of routers atremote points over an Internet Protocol (IP) internetwork. IP-IP is anIP tunneling protocol that encapsulates one IP packet in another IPpacket. To encapsulate IP packet in an IP packet, an outer header isadded with SRC, the entry point of the tunnel and the destination point,the exit point of the tunnel, etc.

As such, in order to establish the tunnel, packet 2105 c's header ischanged to include a GRE/IP header where the SRC is SMTS 240 and the DSTis gateway module 255. Hence, the tunnel start point and end point aredefined in this GRE/IP header. Furthermore, the MAC header is replacedand the SRC is changed to SMTS 240 and the DST is changed to layer-2/3switch 247. The IP header remains the same, and the UDP header alsoremains the same.

Layer-2/3 switch 247 receives packet 2105 c and changes the MAC SRC andDST to Layer-2/3 switch 247 and acceleration modules 650, respectively(packet 2105 d). All other aspects of packet 2105 c's header and payloadremain the same. In one embodiment, acceleration modules 650 store theIP header information in a storage memory in order to preserve theheader. The IP header may be stored in a hash table or any other storageconstruct. The acceleration of the payload occurs and the IP header isretrieved from the storage memory and replaced in packet 2105 e's headeralong with the payload. The SRC and DST are changed to accelerationmodule 650 and Layer-2/3 switch 250, respectively.

Packet 2105 e passes through gateway module 255 (i.e., packet 2105 f),or may proceed directly to point A (e.g., the Internet, an HSIP, etc.).Before travelling to the Internet, packet 2105 g's header has the GRE/IPheader removed, indicating that the packet is out of the packetencapsulation protocol tunnel. As can be seen from packets 2105 a and2105 g, the IP header, the TCP header, and the payload are preserved.Also, accounting occurs after the gateway module 255 and the fullpayload (or bandwidth consumption) is properly accounted for. Thus, norevenue is lost due to compression.

Furthermore, packet header preservation occurs such that, for example,the IP Communications Assistance for Law Enforcement Act (CALEA)requirements are maintained. Since CALEA required that the source andthe destination of each packet is able to be traced, this headerpreservation provides such traceability. Additionally, in oneembodiment, gateway module 255 may include traffic shaping functionally.Traffic shaping on packets within the tunnel is not possible. Further,one benefit of being able to do acceleration in the tunnel is that it ismerely a “bump in the wire.” Since packets coming out of the gatewaymodule 255 are the same as the packets that left the CPE, the MAC-PHYtransformations that occurred are transparent and therefore, externalshapers can be used to enforce network QoS, policies, etc.

In a further embodiment, network 2100 provides the ability fortemporarily stripping away the tunnel encapsulation, acceleration,tracking, shaping, accounting, etc. of the packets, and then putting thetunnel encapsulation back on. The process is transparent to the customerand the network components. For example, if gateway module 255 receivedan ITP packet, gateway module 255 would not know what to do with thepacket. In other words, the packet would not have the correct header orpayload information which gateway module 255 was expecting. Accordingly,significant benefits are achieved.

Turning now to FIG. 22, the diagram illustrates the forward link portionof network 2100. As can be seen from the packet 2205(a-g) headers, thesame or similar process described with respect to FIG. 21 is shown, witheach of the SRCs and DSTs being swapped (i.e., in order to direct thepackets to move back through network 2100).

FIGS. 23A and 23B show block diagrams of one embodiment of flow forimplementing acceleration through a tunnel, according to variousembodiments of the invention. FIG. 23A relates to networks 700-a and700-b as shown in FIGS. 7A-7B. In one embodiment, the acceleration shownin FIGS. 23A and 23B may be implemented by either one of networks 700-aor 700-b. For example, FIG. 23B shows Policy Based Routing (PBR) staticload sharing with IP header preservation. In this example, SMTS 240supports two beams (beam 1 and 2). Furthermore, CPE 160 a is supportedby beam 1 and CPE 160 b is supported by beam 2. Additionally, each beamis supported by an acceleration module and a failover accelerationmodule 2315. Beam 1 is supported by acceleration module 2305 and beam 2is supported by acceleration module 2310.

Similar to FIGS. 21 and 22, packets from CPEs 160 a and 160 b flowthrough the network and enter a packet encapsulation tunnel between SMTS240 and gateway module 255. The solid lined arrows represent the packetflow from CPE 160 a's packets, and the dashed lines represent packetflow for CPE 160 b's packets. Based in part on the encapsulation tunnelkeys associated with each of CPE 160 a and 160 b, the packets aredirected to acceleration modules 2305 and 2310, respectively.Furthermore, if one or more of acceleration module 2305 and 2310 fail,then failover acceleration module 2315 is directed to provideacceleration for the packets for the beam of the failed accelerationmodule. For example, when the layer-2/3 switch 250 detects a linkfailure to acceleration module 2305, or if a health check on theapplication status fails, then traffic is directed to the failoveracceleration module 2315.

FIG. 24 shows a flow diagram of a method 2400 for implementingacceleration through a tunnel, according to various embodiments. Atprocess block 2405, a packet encapsulation tunnel connection between afirst network endpoint and a second network endpoint is established. Thepacket encapsulation protocol may be, for example, a GRE tunnel, anIP-IP tunnel, etc. One problem with tunnels is that since the tunnelpacket header encapsulates the IP packet (as if the IP packet is in anenvelope), determining what is inside the tunneled packet is difficultor impossible, without pulling the packet out of the encapsulation.Accordingly, aspects of method 2400 pull the packets out of the tunnelencapsulation, accelerate the packet data, and then put the packets backinto the encapsulation.

At process block 2410, the packet encapsulation tunnel protocol headermay be removed from the packets and stored in a storage memory (processblock 2415). Once the packet has been “removed” from the tunneling,acceleration, shaping, compression, etc., are performed on the packetpayload data (process block 2420). In one embodiment, the packet may bestored in a hash table, which may be used to map each tunnel key to eachpacket.

Once acceleration and the like is performed, at process block 2425, thetunnel header may be retrieved and replaced in the packet (process block2430). As such, the packet is able to continue being transmitted untilthe packet reaches its destination at the second endpoint (process block2435).

FIG. 25 is a simplified block diagram illustrating the physicalcomponents of a computer system 2500 that may be used in accordance withan embodiment of the present invention. This diagram is merely anexample, which should not unduly limit the scope of the claims. One ofordinary skill in the art would recognize many variations, alternatives,and modifications.

In various embodiments, computer system 2500 may be used to implementany of the computing devices of the present invention. As shown in FIG.25, computer system 2500 comprises hardware elements that may beelectrically coupled via a bus 2524. The hardware elements may includeone or more central processing units (CPUs) 2502, one or more inputdevices 2504 (e.g., a mouse, a keyboard, etc.), and one or more outputdevices 2506 (e.g., a display device, a printer, etc.). For example, theinput devices 2504 are used to receive user inputs for procurementrelated search queries. Computer system 2500 may also include one ormore storage devices 2508. By way of example, storage devices 2508 mayinclude devices such as disk drives, optical storage devices, andsolid-state storage devices such as a random access memory (RAM) and/ora read-only memory (ROM), which can be programmable, flash-updateableand/or the like. In an embodiment, various databases are stored in thestorage devices 2508. For example, the central processing unit 2502 isconfigured to retrieve data from a database and process the data fordisplaying on a GUI.

Computer system 2500 may additionally include a computer-readablestorage media reader 2512, a communications subsystem 2514 (e.g., amodem, a network card (wireless or wired), an infra-red communicationdevice, etc.), and working memory 2518, which may include RAM and ROMdevices as described above. In some embodiments, computer system 2500may also include a processing acceleration unit 2516, which can includea digital signal processor (DSP), a special-purpose processor, and/orthe like.

Computer-readable storage media reader 2512 can further be connected toa computer-readable storage medium 2510, together (and, optionally, incombination with storage devices 2508) comprehensively representingremote, local, fixed, and/or removable storage devices plus storagemedia for temporarily and/or more permanently containingcomputer-readable information. Communications system 2514 may permitdata to be exchanged with network and/or any other computer.

Computer system 2500 may also comprise software elements, shown as beingcurrently located within working memory 2518, including an operatingsystem 2520 and/or other code 2522, such as an application program(which may be a client application, Web browser, mid-tier application,RDBMS, etc.). In a particular embodiment, working memory 2518 mayinclude executable code and associated data structures for one or moreof design-time or runtime components/services. It should be appreciatedthat alternative embodiments of computer system 2500 may have numerousvariations from that described above. For example, customized hardwaremight also be used and/or particular elements might be implemented inhardware, software (including portable software, such as applets), orboth. Further, connection to other computing devices such as networkinput/output devices may be employed. In various embodiments, thebehavior of the view functions described throughout the presentapplication is implemented as software elements of the computer system2500.

In one set of embodiments, the techniques described herein may beimplemented as program code executable by a computer system (such as acomputer system 2500) and may be stored on machine-readable media.Machine-readable media may include any appropriate media known or usedin the art, including storage media and communication media, such as(but not limited to) volatile and non-volatile, removable andnon-removable media implemented in any method or technology for storageand/or transmission of information such as machine-readableinstructions, data structures, program modules, or other data, includingRAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM,digital versatile disk (DVD) or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to store ortransmit the desired information and which can be accessed by acomputer.

While the principles of the disclosure have been described above inconnection with specific apparatuses and methods, it is to be clearlyunderstood that this description is made only by way of example and notas limitation on the scope of the disclosure. Further, while theinvention has been described with respect to exemplary embodiments, oneskilled in the art will recognize that numerous modifications arepossible. For example, the methods and processes described herein may beimplemented using hardware components, software components, and/or anycombination thereof. Further, while various methods and processesdescribed herein may be described with respect to particular structuraland/or functional components for ease of description, methods of theinvention are not limited to any particular structural and/or functionalarchitecture but instead can be implemented on any suitable hardware,firmware and/or software configuration. Similarly, while variousfunctionality is ascribed to certain system components, unless thecontext dictates otherwise, this functionality can be distributed amongvarious other system components in accordance with different embodimentsof the invention.

Moreover, while the procedures comprised in the methods and processesdescribed herein are described in a particular order for ease ofdescription, unless the context dictates otherwise, various proceduresmay be reordered, added, and/or omitted in accordance with variousembodiments of the invention. Moreover, the procedures described withrespect to one method or process may be incorporated within otherdescribed methods or processes; likewise, system components describedaccording to a particular structural architecture and/or with respect toone system may be organized in alternative structural architecturesand/or incorporated within other described systems. Hence, while variousembodiments are described with—or without—certain features for ease ofdescription and to illustrate exemplary features, the various componentsand/or features described herein with respect to a particular embodimentcan be substituted, added and/or subtracted from among other describedembodiments, unless the context dictates otherwise. Consequently,although the invention has been described with respect to exemplaryembodiments, it will be appreciated that the invention is intended tocover all modifications and equivalents within the scope of thefollowing claims.

What is claimed is:
 1. A satellite communication system, comprising: afirst satellite configured to provide network access to a firstplurality of user terminals within a first spot beam; a second satelliteconfigured to provide network access to a second plurality of userterminals within a second spot beam; a first gateway of a ground segmentnetwork, the first gateway configured to communicate with the firstplurality of user terminals within the first spot beam via the firstsatellite; a second gateway of the ground segment network, the secondgateway configured to communicate with the second plurality of userterminals within the second spot beam via the second satellite; and acore node of the ground segment network, the core node in communicationwith the first gateway and the second gateway, and configured toestablish a private network including both the first plurality of userterminals and the second plurality of user terminals, wherein the corenode utilizes a dynamic address allocation service for allocatingrespective network addresses of the private network to both the firstplurality of user terminals and the second plurality of user terminals.2. The satellite communication system of claim 1, wherein the core nodeis further configured to: receive a service request for the dynamicaddress allocation service from a first user terminal of the firstplurality of user terminals while the first user terminal is at a firstlocation within the first spot beam; allocate a first network address ofthe private network to the first user terminal based at least in part onthe service request; and maintain the first network address for thefirst user terminal upon the first user terminal moving from the firstlocation to a second location within the second spot beam.
 3. Thesatellite communication system of claim 1, wherein the first gateway andthe second gateway are a same gateway.
 4. The satellite communicationsystem of claim 1, wherein the first gateway is different from thesecond gateway.
 5. The satellite communication system of claim 1,wherein the core node comprises a first core node configured to providethe dynamic address allocation service for the first gateway and asecond core node configured to provide the dynamic address allocationservice for the second gateway.
 6. The satellite communication system ofclaim 1, wherein the first satellite communicates with the firstplurality of user terminals within the first spot beam via a firstfrequency band.
 7. The satellite communication system of claim 6,wherein the second satellite communicates with the second plurality ofuser terminals within the second spot beam via a second frequency bandthat is different from the first frequency band.
 8. The satellitecommunication system of claim 1, wherein the first gateway and thesecond gateway are non-autonomous gateways.
 9. The satellitecommunication system of claim 1, wherein the first gateway and thesecond gateway comprise a network interface configured to generatepacket headers for respective data packets associated withcommunications between the first gateway and the second gateway and boththe first plurality of user terminals and the second plurality of userterminals, each of the packet headers comprising a medium access control(MAC) header associated with the private network.
 10. The satellitecommunication system of claim 9, wherein the first gateway and thesecond gateway are further configured to: generate virtual taggingtuples for the respective data packets based on an association betweenboth the first plurality of user terminals and the second plurality ofuser terminals and one or more entities; and transmit the respectivedata packets to the one or more entities based on each of the virtualtagging tuples associated with each of the respective data packets. 11.The satellite communication system of claim 10, wherein the virtualtagging tuples each are associated with a portion of communication linkcapacity of the ground segment network reserved for a respective entityof the one or more entities.
 12. The satellite communication system ofclaim 10, wherein the first gateway and the second gateway furthercomprise a satellite modem termination system configured to encapsulatethe respective data packets according to an encapsulation tunnelingprotocol, and wherein respective end point for the encapsulation are oneor more nodes of the ground segment network associated with the one ormore entities.
 13. The satellite communication system of claim 1,wherein the core node is in communication with the first gateway and thesecond gateway at layer-2 of an Open System Interconnection Model.
 14. Amethod of satellite communication, comprising: communicating, by a firstgateway of a ground segment network, with a first plurality of userterminals within a first spot beam associated with a first satelliteconfigured to provide network access to the first plurality of userterminals; communicating, by a second gateway of the ground segmentnetwork, with a second plurality of user terminals within a second spotbeam associated with a second satellite configured to provide networkaccess to the second plurality of user terminals; establishing, by acore node of the ground segment network in communication with the firstgateway and the second gateway, a private network including both thefirst plurality of user terminals and the second plurality of userterminals, wherein the core node utilizes a dynamic address allocationservice for allocating respective network addresses of the privatenetwork to both the first plurality of user terminals and the secondplurality of user terminals.
 15. The method of claim 14, furthercomprising: receiving a service request for the dynamic addressallocation service from a first user terminal of the first plurality ofuser terminals while the first user terminal is at a first locationwithin the first spot beam; allocating a first network address of theprivate network to the first user terminal based at least in part on theservice request; and maintaining the first network address for the firstuser terminal upon the first user terminal moving from the firstlocation to a second location within the second spot beam.
 16. Themethod of claim 14, wherein the first gateway and the second gateway area same gateway.
 17. The method of claim 14, wherein the first gateway isdifferent from the second gateway.
 18. The method of claim 14, whereinthe core node comprises a first core node and a second core node, andwherein establishing the private network by the core node comprisesproviding the dynamic address allocation service for the first gatewayby the first core node and providing the dynamic address allocationservice for the second gateway by the second core node.
 19. The methodof claim 14, wherein the first satellite communicates with the firstplurality of user terminals within the first spot beam via a firstfrequency band.
 20. The method of claim 19, wherein the second satellitecommunicates with the second plurality of user terminals within thesecond spot beam via a second frequency band that is different from thefirst frequency band.
 21. The method of claim 14, wherein the firstgateway and the second gateway are non-autonomous gateways.
 22. Themethod of claim 14, further comprising: generating, at the first gatewayand the second gateway, packet headers for respective data packetsassociated with communications between the first gateway and the secondgateway and both the first plurality of user terminals and the secondplurality of user terminals, each of the packet headers comprising amedium access control (MAC) header associated with the private network.23. The method of claim 22, further comprising: generating virtualtagging tuples for the respective data packets based on an associationbetween both the first plurality of user terminals and the secondplurality of user terminals and one or more entities; and transmittingthe respective data packets to the one or more entities based on each ofthe virtual tagging tuples associated with each of the respective datapackets.
 24. The method of claim 23, wherein the virtual tagging tupleseach are associated with a portion of communication link capacity of theground segment network reserved for a respective entity of the one ormore entities.
 25. The method of claim 23, further comprising:encapsulating the respective data packets according to an encapsulationtunneling protocol, wherein respective end point for the encapsulationare one or more nodes of the ground segment network associated with theone or more entities.
 26. The method of claim 14, wherein the core nodeis in communication with the first gateway and the second gateway atlayer-2 of an Open System Interconnection Model.